UDDI Spec TC

Document Identifier:

uddi-spec-tc-tn-wsdl-v2

This Version:

http://www.oasis-open.org/committees/uddi-spec/doc/tn/uddi-spec-tc-tn-wsdl-v202-20040631.htm

Latest Version:

http://www.oasis-open.org/committees/uddi-spec/doc/tn/uddi-spec-tc-tn-wsdl-v2.htm

Previous Version:

http://www.oasis-open.org/committees/uddi-spec/doc/tn/uddi-spec-tc-tn-wsdl-v200-20031104.htm

Authors (alphabetically):

John Colgrave, IBM, colgrave@uk.ibm.com

Karsten Januszewski, Microsoft, karstenj@microsoft.com

Editors:

Luc Clément, Systinet Corporation, luc.clement@systinet.com

Tony Rogers, Computer Associates, tony.rogers@ca.com

Abstract:

This document is an OASIS UDDI Technical Note that defines a new approach to using WSDL in a UDDI Registry.

Status:

This document is updated periodically on no particular schedule.

Committee members should send comments on this technical note to the uddi-spec@lists.oasis-open.org list. Others should submit comments via http://www.oasis-open.org/committees/comments/form.php?wg_abbrev=uddi-spec.

For information on whether any intellectual property claims have been disclosed that may be essential to implementing this technical note, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the UDDI Spec TC web page (http://www.oasis-open.org/committees/uddi-spec/ipr.php).

 

1      Introduction. 5

1.1        Goals and Requirements. 5

1.2        Relationship to Version 1 Best Practice. 6

1.3        Terminology. 6

2      Mapping Two Data Models: WSDL & UDDI 7

2.1        WSDL Data Model 7

2.1.1     portType. 7

2.1.2     binding. 8

2.1.3     service and port 8

2.1.4     import 8

2.2        UDDI Data Model 8

2.2.1     tModels. 8

2.2.2     businessService & bindingTemplate. 9

2.3        Mapping WSDL and UDDI 9

2.3.1     Mapping Overview. 10

2.3.2     Comparison to Version 1 Mapping. 11

2.3.3     New Canonical tModels. 11

2.3.4     General Conventions. 11

2.3.5     Support for Multiple UDDI API Versions. 11

2.3.6     References to WSDL Components. 12

2.3.7     WSDL Extensibility Elements. 12

2.3.8     Support for WSDL Implementation Documents. 12

2.4        Mapping WSDL 1.1 in UDDI V2. 12

2.4.1     wsdl:portType -> uddi:tModel 12

2.4.2     wsdl:binding -> uddi:tModel 13

2.4.3     wsdl:service -> uddi:businessService. 15

2.4.4     wsdl:port -> uddi:bindingTemplate. 16

2.4.5     wsdl:port Address Extensions -> uddi:bindingTemplate. 17

2.5        Differences in mapping WSDL 1.1 in UDDI V3. 18

2.5.1     Mandatory Differences. 18

2.5.2     Comparison to wsdlDeployment in UDDI V3 Specification. 18

3      A Complete Example. 19

3.1        WSDL Sample. 19

3.2        UDDI V2 Model 20

3.2.1     UDDI portType tModel 20

3.2.2     UDDI binding tModel 20

3.2.3     UDDI businessService and bindingTemplate. 21

3.3        Sample V2 Queries. 22

3.3.1     Find tModel for portType name. 22

3.3.2     Find bindings for portType. 22

3.3.3     Find Implementations of portType. 23

3.3.4     Find implementations of binding. 23

3.3.5     Find SOAP Implementations of portType. 23

3.3.6     Find SOAP/HTTP Implementations of portType. 24

3.3.7     Find the portType of a binding. 24

3.3.8     Find the businessService for a WSDL service. 24

3.4        Sample V3 Queries. 25

3.4.1     Find Implementations of portType. 25

3.4.2     Find SOAP Implementations of portType. 25

4      References. 26

4.1        Normative. 26

A      External WSDL Implementation Documents. 27

A.1 Capturing The URL. 27

A.2 Obtaining the Port Address from WSDL. 27

A.3 Querying Services that use a WSDL Implementation Document 27

B      Canonical tModels. 28

B.1 WSDL Entity Type tModel 28

B.1.1 Design Goals. 28

B.1.2 Definition. 28

B.1.3 Valid Values. 28

B.1.4 Example of Use. 29

B.2 XML Namespace tModel 29

B.2.1 Design Goals. 29

B.2.2 Definition. 29

B.2.3 Valid Values. 30

B.2.4 Example of Use. 30

B.3 XML Local Name tModel 30

B.3.1 Design Goals. 30

B.3.2 Definition. 31

B.3.3 Valid Values. 31

B.3.4 Example of Use. 31

B.4 WSDL portType Reference tModel 31

B.4.1 Design Goals. 31

B.4.2 Definition. 32

B.4.3 Valid Values. 32

B.4.4 Example of Use. 32

B.5 SOAP Protocol tModel 33

B.5.1 Design Goals. 33

B.5.2 Definition. 33

B.5.3 Example of Use. 33

B.6 HTTP Protocol tModel 34

B.6.1 Design Goals. 34

B.6.2 Definition. 34

B.6.3 Example of Use. 34

B.7 Protocol Categorization. 35

B.7.1 Design Goals. 35

B.7.2 Definition. 35

B.7.3 Valid Values. 36

B.7.4 Example of Use. 36

B.8 Transport Categorization. 37

B.8.1 Design Goals. 37

B.8.2 Definition. 37

B.8.3 Valid Values. 37

B.8.4 Example of Use. 38

B.9 WSDL Address tModel 38

B.9.1 Design Goals. 38

B.9.2 Definition. 38

B.9.3 Valid Values. 39

B.9.4 Example of Use. 39

C      Using XPointer in overviewURL. 40

C.1 XPointer Syntax. 40

C.1.1 Example of Use. 40

D      Acknowledgments. 41

E      Revision History. 42

F      Notices. 43

 

The Universal Description, Discovery & Integration (UDDI) specification provides a platform-independent way of describing and discovering Web services and Web service providers. The UDDI data structures provide a framework for the description of basic service information, and an extensible mechanism to specify detailed service access information using any standard description language. Many such languages exist in specific industry domains and at different levels of the protocol stack. The Web Services Description Language (WSDL) is a general purpose XML language for describing the interface, protocol bindings, and the deployment details of network services. WSDL complements the UDDI standard by providing a uniform way of describing the abstract interface and protocol bindings of arbitrary network services. The purpose of this document is to clarify the relationship between the two and to describe a recommended approach to mapping WSDL descriptions to the UDDI data structures.

Consistent and thorough WSDL mappings are critical to the utility of UDDI.

1.1                 Goals and Requirements

The primary goals of this mapping are:

1. To enable the automatic registration of WSDL definitions in UDDI
2. To enable precise and flexible UDDI queries based on specific WSDL artifacts and metadata
3. To maintain compatibility with the mapping described in the Using WSDL in a UDDI Registry, Version 1.08 [1] Best Practice document
4. To provide a consistent mapping for UDDI Version 2 and UDDI Version 3
5. To support any logical and physical structure of WSDL description

This mapping prescribes a consistent methodology to map WSDL 1.1 artifacts to UDDI structures. It describes an approach that represents reusable, abstract Web service artifacts, (WSDL portTypes and WSDL bindings) and Web service implementations (WSDL services and ports). Tools can use this mapping to generate UDDI registrations automatically from WSDL descriptions.

This mapping captures sufficient information from the WSDL documents to allow precise queries for Web services information without further recourse to the source WSDL documents, and to allow the appropriate WSDL documents to be retrieved once a match has been found. Given that the source WSDL documents can be distributed among the publishers using a UDDI registry, a UDDI registry provides a convenient central point where such queries can be executed.

This mapping enables the following types of queries for both design-time and run-time discovery:

·         Given the namespace and/or local name of a wsdl:portType, find the tModel that represents that portType.

·         Given the namespace and/or local name of a wsdl:binding, find the tModel that represents that binding.

·         Given a tModel representing a portType, find all tModels representing bindings for that portType.

·         Given a tModel representing a portType, find all bindingTemplates that represent implementations of that portType.

·         Given a tModel representing a binding, find all bindingTemplates that represent implementations of that binding.

·         Given the namespace and/or local name of a wsdl:service, find the businessService that represents that service.

Some aspects of the mapping allow information to be retrieved directly without further queries being necessary. For example, given the tModel representing a binding, it is possible to retrieve the key of the tModel representing the portType referred to by the binding. Other aspects of the mapping may require multiple queries to be issued to the UDDI registry.

Although the UDDI V3 data model is slightly different from the UDDI data model, this mapping ensures that the same information is captured in both versions.

1.2                 Relationship to Version 1 Best Practice

This document builds on Using WSDL in a UDDI Registry, Version 1.08, providing an expanded modeling practice that encompasses the flexibility of WSDL. The primary difference between this mapping and the one described in the existing Best Practice is that this mapping provides a methodology to represent individual Web services artifacts.

As a Technical Note, this document does not replace the Version 1 Best Practice. If the additional flexibility is not required, the existing Best Practice can still be used, particularly when the UDDI artifacts are published manually.

It is anticipated that implementations of the approach described in this Technical Note will be developed, and that once experience with those implementations is obtained this Technical Note will become a Best Practice.

A final goal is to be compatible with the existing Best Practice in that a tModel representing a WSDL binding published using the approach described in this document should be usable by a client that uses the Version 1 Best Practice approach.

1.3                 Terminology

The key words must, must not, required, shall, shall not, should, should not, recommended, may, and optional in this document are to be interpreted as described in [RFC2119].

A brief discussion of the two respective data models, WSDL and UDDI, follows. For a complete explanation of these specifications, see [2], [3], and [4].

2.1                 WSDL Data Model

A review of WSDL in the context of the goals and requirements will help guide a new mapping practice in UDDI.

2.1.1            portType

The central construct in WSDL is the portType. A portType is an abstract collection of operations that may be supported by one or more Web services. A WSDL portType defines these operations in terms of message definitions, which usually rely on the XML Schema language to describe the representation of each message. A single WSDL document may contain multiple portType entities. Each portType is uniquely identified by the combination of its local name and the target namespace of the definitions element that contains the portType.

WSDL portTypes may be implemented by more than one Web service. Web services that purport to support a given portType must adhere not only to the message formats that are part of the WSDL definition; they must also adhere to the semantic agreement that is implicitly part of the portType. This consistency allows applications to treat two Web services as substitutable if and only if they implement a common portType.

2.1.2            binding

WSDL portTypes are abstract Web service descriptions and do not specify information about the encoding and transport protocols used to transmit the messages. To specify encoding and transport protocol details in WSDL, one must define a second construct, known as a binding. A WSDL binding specifies a specific set of encoding and transport protocols that may be used to communicate with an implementation of a particular WSDL portType. A WSDL binding specifies its portType through a QName reference. The referenced portType may or may not be in the same target namespace as the binding itself. Again, a single WSDL document may contain multiple bindings. For example, a WSDL document may describe multiple protocol bindings for a single portType. Like a portType, a binding is uniquely identified by the combination of its local name and the target namespace of the definitions element that contains the binding.

As with portTypes, WSDL bindings are abstract definitions and do not represent a Web service implementation. Multiple Web services may implement the same WSDL binding.

2.1.3            service and port

Finally, WSDL defines a Web service implementation as a service with a collection of named ports. Each port implements a particular portType using the protocols defined by a named binding. A service may expose multiple ports in order to make a single portType available over multiple protocols. A service may also expose multiple ports in order to expose more than one portType from a single logical entity. A WSDL port specifies the binding it implements through a QName reference. The referenced binding may or may not be in the same target namespace as the port itself. A single WSDL document may contain multiple services. A service is uniquely identified by the combination of its local name and the target namespace of the definitions element that contains the service. Likewise, a port is uniquely identified by the combination of its local name and the target namespace of the definitions element that contains the port.

2.1.4            import

The import directive in WSDL allows the separation of these different entities into multiple files. As such, a WSDL document may be composed of a single portType, multiple portTypes, a single binding that imports its portType definition, multiple bindings, a single service, or multiple services, etc. The WSDL data model provides great flexibility in terms of composition and reusability of WSDL entities. 

Given this flexibility, the critical components of a WSDL document in terms of composition and identity are the target namespace of the definitions element and the local names that identify each portType, binding, service, and port within the target namespace. 

2.2                 UDDI Data Model

As an aid to understanding the sections ahead, we provide here a brief overview of two UDDI data structures that are particularly relevant to the use of WSDL in the context of a UDDI registry: the tModel and the businessService.

2.2.1            tModels

TModels are often referred to as service type definitions. TModels represent unique concepts or constructs. They are used to describe compliance with a specification, a concept, or a shared design. TModels have various uses in the UDDI registry. In the case of mapping WSDL-described Web services, tModels have two uses. First, tModels are used to represent technical specifications such as service types, bindings, and wire protocols. Second, tModels are used to implement category systems that are used to categorize technical specifications and services. This Technical Note defines a set of specification and category system tModels that are used when mapping WSDL entities to UDDI entities. These tModels are defined in Appendix B.

When a particular specification is registered in the UDDI registry as a tModel, it is assigned a unique key, called a tModelKey. This key is used by other UDDI entities to reference the tModel, for example to indicate compliance with the specification.

Each specification tModel contains an overviewURL, which provides the address of the specification itself, for example, a WSDL document.

Additional metadata can be associated with a specification tModel using any number of identifier and category systems. Identifiers are grouped in a construct called an identifierBag, and categories are grouped in a construct called a categoryBag. These bags contain a set of keyedReference elements. Each keyedReference specifies the tModelKey of the category system tModel and a name/value pair that specifies the metadata. For example, a keyedReference referencing the namespace category system can be used to specify a WSDL namespace. The metadata values specified in keyedReference elements can be used as selection criteria when searching UDDI.

2.2.2            businessService & bindingTemplate

 

 

Services are represented in UDDI by the businessService data structure, and the details of how and where the service is accessed are provided by one or more bindingTemplate structures. The businessService might be thought of as a logical container of services. The bindingTemplate structure contains the accessPoint of the service, as well as references to the tModels it is said to implement.

2.3                 Mapping WSDL and UDDI

WSDL is designed to support modular and reusable definitions, and each definition artifact has certain relationships with other definition artifacts. As described in Section 1.1, the goals of this technical note and the mapping it defines are to enable the automatic registration of WSDL definitions in UDDI, to enable precise and flexible UDDI queries based on specific WSDL artifacts and metadata, to maintain compatibility with the Version 1 Best Practice methodology, and to provide a consistent mapping for both UDDI V2 and UDDI V3. The mapping itself addresses the first goal. The second goal provides the rationale for the methodology used in this mapping. In order to support queries based on specific WSDL artifacts and metadata, this mapping must be able to represent the individual WSDL artifacts and the relationships between artifacts. This goal also provides the rationale for the amount of information that must be captured in UDDI. Additional information must also be included in some cases to support the third goal. To address the fourth goal, the information captured in the two mappings is as consistent as possible.

2.3.1            Mapping Overview

This mapping describes a methodology for mapping WSDL 1.1 definitions to the UDDI V2 and UDDI V3 data models. The methodology maps each WSDL artifact to a separate UDDI entity, accurately representing the "building block" design of WSDL descriptions. wsdl:portType and wsdl:binding elements map to uddi:tModel entities, wsdl:service elements map to uddi:businessService entities and wsdl:port elements map to uddi:bindingTemplate entities. KeyedReferences provide a mechanism to express additional metadata and to represent a relationship between two UDDI entities.

 

2.3.2            Comparison to Version 1 Mapping

One important thing to note about this mapping, especially as compared to the mapping described in the Version 1 Best Practice, is that this approach may map a single WSDL document to multiple tModels. For example, a single WSDL document that contains one portType definition and two binding definitions will map to three distinct tModels in UDDI. This approach differs from the Version 1 Best Practice, which would, by default, map the entire WSDL document to a single tModel. The Version 1 Best Practice does not allow for a portType to map to a distinct tModel.  The rationale for this new mapping decision is to more effectively represent the modularity and reusability of WSDL artifacts in UDDI. A Web service implementation might implement only one of the bindings described in a WSDL document. By decomposing WSDL into multiple tModels, one can accurately model in UDDI exactly which portTypes and bindings a given Web service implementation supports, as opposed to being constrained to asserting that a Web service always supports the entirety of the WSDL document. 

While there is an increased amount of data from a WSDL document modeled in UDDI, this new approach is in accord with the Version 1 Best Practice in that it does not attempt to use UDDI as a repository for all of the data in a WSDL document. Just as in the Version 1 Best Practice, one still must go outside of the UDDI registry to retrieve the portType and binding information necessary for software applications to work with that Web service.

2.3.3            New Canonical tModels

This mapping introduces a number of canonical tModels that are used to represent WSDL metadata and relationships. These tModels, including the WSDL Entity Type tModel, the XML Namespace tModel, the XML Local Name tModel, the WSDL portType Reference tModel, the SOAP Protocol tModel, the HTTP Protocol tModel, the Protocol Categorization tModel, the Transport Categorization tModel and the WSDL Address tModel, are described in Appendix B. These tModels MUST be registered in the UDDI registry to support this mapping.  Both V1/V2 and V3 keys are given for these tModels.

2.3.4            General Conventions

In this mapping, each WSDL artifact is mapped to its corresponding UDDI entity. A set of keyedReference elements is added to each UDDI entity to capture additional metadata. In order to support the requirements outlined in Section 1.1, the following metadata is captured for each entity:

·         The type of WSDL entity being defined (i.e., portType, binding, service, or port)

·         The target namespace of the WSDL definitions file that defines the WSDL entity

·         The local name of the WSDL entity being defined

·         The location of the WSDL document that defines the WSDL entity is captured for portType, binding and, optionally, service entities.

Any relationships and dependencies between entities must also be captured. For example, a tModel that represents a binding provides a reference to the tModel that represents the portType implemented by the binding.

To maintain compatibility with the Version 1 Best Practice mapping, certain UDDI entities are also characterized as being of type "wsdlSpec".

2.3.5            Support for Multiple UDDI API Versions

The mapping described is designed to appear the same whichever version of the UDDI API is used to access it.  There are differences that are mandated by the differences in the API versions, and such differences are noted in the appropriate sections.

2.3.6            References to WSDL Components

A UDDI entity normally references technical specifications using the overviewURL element. As noted above, in this mapping a single WSDL document may map to multiple tModels, and each tModel refers to a particular WSDL entity within the file. The particular WSDL entity is uniquely identified by the combination of its local name and the target namespace of the definitions element that contains the WSDL entity. This identity information SHOULD be determined from the UDDI entity, using the particular mapping for the namespace name and local name applicable to the particular UDDI entity type. Alternatively, the overviewURL value MAY contain a fragment identifier that identifies the particular WSDL entity. If the optional fragment identifier is used, then the value of the overviewURL SHOULD conform to the syntax described in Appendix C.

2.3.7            WSDL Extensibility Elements

WSDL uses extensibility elements to describe technology-specific information within a WSDL definition. Extensibility elements may be included under many of the WSDL elements. The only extensibility elements that are relevant to this mapping are binding and port extensions, specifically the extensibility elements that can be added to the wsdl:binding and wsdl:port elements. The first of these is used to declare particular protocols and message formats; the second is to provide address information.

Information from these extensibility elements is mapped to the tModel for a wsdl:binding and the bindingTemplate for a wsdl:port. The mappings defined in this document include details on the SOAP 1.1 and HTTP GET/POST bindings defined in the WSDL 1.1 W3C Note. The mappings also describe how other bindings should be incorporated into the UDDI mapping.

2.3.8            Support for WSDL Implementation Documents

In the context of this Technical Note, a WSDL Implementation Document is a WSDL document that contains at least one wsdl:service element and its associated wsdl:port elements.  There are two options for how this implementation information is described in UDDI:

1. The information in the UDDI model is the authoritative information and there is no reference to a WSDL Implementation Document.
2. A reference to an external WSDL Implementation Document can be stored in UDDI and the remaining information in UDDI is used to describe the appropriate element in the external WSDL resource.

The mapping described in the body of this document corresponds to the first option above, and that is assumed to be the default mapping. The second option is described in Appendix A.

2.4                 Mapping WSDL 1.1 in UDDI V2

This section describes a detailed mapping of WSDL 1.1 artifacts to the UDDI V2 data model.

2.4.1            wsdl:portType -> uddi:tModel

A wsdl:portType MUST be modeled as a uddi:tModel.

The minimum information that must be captured about a portType is its entity type, its local name, its namespace, and the location of the WSDL document that defines the portType. Capturing the entity type enables users to search for tModels that represent portType artifacts. Capturing the local name, namespace, and WSDL location enables users to locate the definition of the specified portType artifact.

The wsdl:portType information is captured as follows:

The uddi:name element of the tModel MUST be the value of the name attribute of the wsdl:portType.

The tModel MUST contain a categoryBag, and the categoryBag MUST contain a keyedReference with a tModelKey of the WSDL Entity Type category system and a keyValue of "portType".

If the wsdl:portType has a targetNamespace then the categoryBag MUST also contain an additional keyedReference with a tModelKey of the XML Namespace category system and a keyValue of the target namespace of the wsdl:definitions element that contains the wsdl:portType. If the targetNamespace is absent from the portType, a categoryBag MUST NOT contain a keyedReference to the XML Namespace category system.

The tModel MUST contain an overviewDoc with an overviewURL containing the location of the WSDL document that describes the wsdl:portType.

2.4.1.1      Summary of Mapping of wsdl:portType

WSDL	UDDI
portType	tModel (categorized as portType)
Namespace of portType	keyedReference in categoryBag
Local name of portType	tModel name
Location of WSDL document	overviewURL

 

2.4.2            wsdl:binding -> uddi:tModel

A wsdl:binding MUST be modeled as a uddi:tModel.

The minimum information that must be captured about a binding is its entity type, its local name, its namespace, the location of the WSDL document that defines the binding, the portType that it implements, its protocol, and, optionally, the transport information. Capturing the entity type enables users to search for tModels that represent binding artifacts. Capturing the local name, namespace, and WSDL location enables users to locate the definition of the specified binding artifact. The link to the portType enables users to search for bindings that implement a particular portType.

A wsdl:binding corresponds to a WSDL service interface definition as defined by the mapping in the Version 1 Best Practice. To maintain compatibility with the previous mapping, the binding must also be characterized as type "wsdlSpec".

The wsdl:binding information is captured as follows:

The uddi:name element of the tModel MUST be the value of the name attribute of the wsdl:binding.

The tModel MUST contain a categoryBag, and the categoryBag MUST contain at least the following keyedReference elements:

1. A keyedReference with a tModelKey of the WSDL Entity Type category system and a keyValue of "binding".
2. A keyedReference with a tModelKey of the WSDL portType Reference category system and a keyValue of the tModelKey that models the wsdl:portType to which the wsdl:binding relates.
3. A keyedReference with a tModelKey of the UDDI Types category system and a keyValue of "wsdlSpec" for backward compatibility[1].
4. One or two keyedReferences as required to capture the protocol and optionally the transport information – refer to the next section.

If the wsdl:binding has a targetNamespace then the categoryBag MUST also contain an additional keyedReference with a tModelKey of the XML Namespace category system and a keyValue of the target namespace of the wsdl:definitions element that contains the wsdl:binding. If the targetNamespace is absent from the binding, a categoryBag MUST NOT contain a keyedReference to the XML Namespace category system.

The tModel MUST contain an overviewDoc with an overviewURL containing the location of the WSDL document that describes the wsdl:binding. 

2.4.2.1      wsdl:binding Extensions

Information about the protocol and transport, if applicable, specified in an extension to the wsdl:binding is used to categorize the binding tModel as described in the following sections.  This information is specified using two of the category systems defined in this Technical Note:

1. Protocol Categorization
2. Transport Categorization

The valid values for the Protocol Categorization category system are tModelKeys of tModels that are categorized as protocol tModels.  Similarly, the valid values for the Transport Categorization category system are tModelKeys of tModels that are categorized as transport tModels.

The reason for having these two categorization schemes that take tModel keys as values is to allow other standard or proprietary protocols and transports to be defined and used in the same way as the standard SOAP and HTTP protocols and transport.

2.4.2.1.1               soap:binding

If the wsdl:binding contains a soap:binding extensibility element from the http://schemas.xmlsoap.org/wsdl/soap/ namespace then the categoryBag MUST include a keyedReference with a tModelKey of the Protocol Categorization category system and a keyValue of the tModelKey of the SOAP Protocol tModel.

If the value of the transport attribute of the soap:binding element is http://schemas.xmlsoap.org/soap/http then the categoryBag MUST include a keyedReference with a tModelKey of the Transport Categorization category system and a keyValue of the tModelKey of the HTTP Transport tModel.

If the value of the transport attribute is anything else, then the bindingTemplate MUST include an additional keyedReference with a tModelKey of the Transport Categorization category system and a keyValue of the tModelKey of an appropriate transport tModel.

2.4.2.1.2               http:binding

If the wsdl:binding contains an http:binding extensibility element from the http://schemas.xmlsoap.org/wsdl/http/ namespace then the categoryBag MUST include a keyedReference with a tModelKey of the Protocol Categorization category system and a keyValue of the tModelKey of the HTTP Protocol tModel.

Note that this is a different tModel from the HTTP Transport tModel, and in this case there is no separate transport tModel, and therefore no keyedReference in the categoryBag from the Transport Categorization category system.

2.4.2.1.3               Other wsdl:binding Extensions

Other wsdl:binding extensibility elements are handled in a similar fashion. It is assumed that vendors who provide other bindings will provide the appropriate protocol and transport tModels.

2.4.2.2      Summary of Mapping of wsdl:binding

WSDL	UDDI
binding	tModel (categorized as binding and wsdlSpec)
Namespace of binding	keyedReference in categoryBag
Local name of binding	tModel name
Location of WSDL document	overviewURL
portType binding relates to	keyedReference in categoryBag
Protocol from binding extension	keyedReference in categoryBag
Transport from binding extension (if there is one)	keyedReference in categoryBag

 

2.4.3            wsdl:service -> uddi:businessService

A wsdl:service MUST be modeled as a uddi:businessService. An existing businessService MAY be used or a new businessService MAY be created[2].  Only one wsdl:service can be modeled by an individual uddi:businessService.

The minimum information that must be captured about a service is its entity type, its local name, its namespace, and the list of ports that it supports. Capturing the entity type enables users to search for services that are described by a WSDL definition. The list of ports provides access to the technical information required to consume the service.

The wsdl:service information is captured as follows:

If a new businessService is created, the uddi:name elements of this businessService SHOULD be human readable names, although if no human readable names are specified, exactly one uddi:name MUST be added, containing the value of the name attribute of the wsdl:service[3].

The businessService MUST contain a categoryBag, and the categoryBag MUST contain at least the following keyedReference elements:

1. A keyedReference with a tModelKey of the WSDL Entity Type category system and a keyValue of "service".
2. A keyedReference with a tModelKey of the XML Local Name category system and a keyValue that is the value of the name attribute of the wsdl:service.

If the wsdl:service has a targetNamespace then the categoryBag MUST also contain an additional keyedReference with a tModelKey of the XML Namespace category system and a keyValue of the target namespace of the wsdl:definitions element that contains the wsdl:service. If the targetNamespace is absent from the service, a categoryBag MUST NOT contain a keyedReference to the XML Namespace category system.

The bindingTemplates element of the businessService MUST include bindingTemplate elements that model the ports of the service, as described in the following sections.

2.4.3.1      Summary of Mapping

WSDL	UDDI
Service	businessService (categorized as service)
Namespace of Service	keyedReference in categoryBag
Local Name of Service	keyedReference in categoryBag; optionally also the name of the service

2.4.4            wsdl:port -> uddi:bindingTemplate

A wsdl:port MUST be modeled as a uddi:bindingTemplate.

The minimum information that must be captured about a port is the binding that it implements, the portType that it implements, and its local name[4].

By capturing the binding, users can search for services that implement a specific binding. By capturing the portType, users can search for services that implement a particular portType without necessarily knowing the specific binding implemented by the service.

The wsdl:port information is captured as follows:

The bindingTemplate tModelInstanceDetails element MUST contain at least the following tModelInstanceInfo elements:

1. A tModelInstanceInfo with a tModelKey of the tModel that models the wsdl:binding that this port implements. The instanceParms of this tModelInstanceInfo MUST contain the wsdl:port local name.
2. A tModelInstanceInfo with a tModelKey of the tModel that models the wsdl:portType.

2.4.4.1      Summary of Mapping

WSDL	UDDI
port	bindingTemplate
Namespace	Captured in keyedReference of the containing businessService
Local Name of port	instanceParms of the tModelInstanceInfo relating to the tModel for the binding
Binding implemented by port	tModelInstanceInfo with tModelKey of the tModel corresponding to the binding
portType implemented by port	tModelInstanceInfo with tModelKey of the tModel corresponding to the portType

 

2.4.5            wsdl:port Address Extensions -> uddi:bindingTemplate

The uddi:bindingTemplate MUST contain address information for the Web service. This information comes from the wsdl:port address extensibility element.

2.4.5.1      soap:address -> uddi:accessPoint

A soap:address MUST be modeled as a uddi:accessPoint in the uddi:bindingTemplate that models the wsdl:port that contains the soap:address.

The soap:address information is captured as follows:

·         The accessPoint value MUST be the value of the location attribute of the soap:address element.

·         The URLType attribute of the accessPoint MUST correspond to the transport specified by the soap:binding, or "other" if no correspondence exists. In the case of the HTTP transport, for example, the URLType attribute MUST be "http".

If "other" is used then a tModelInstanceInfo element referencing the appropriate vendor-defined transport tModel MUST be added to the bindingTemplate.

2.4.5.2      http:address -> uddi:accessPoint

An http:address MUST be modeled as a uddi:accessPoint in the uddi:bindingTemplate that models the wsdl:port that contains the http:address.

The http:address information is captured as follows:

·         The accessPoint value MUST be the value of the location attribute of the http:address element.

·         The URLType attribute of the accessPoint MUST be "http" or "https" as appropriate.

2.4.5.3      Other wsdl:port Address Extensions

Any other address extensibility element MUST be modeled as a uddi:accessPoint in the uddi:bindingTemplate that models the wsdl:port that contains the address extensibility element.

The address information is captured as follows:

·         The accessPoint value MUST be the value of the location attribute of the address extensibility element.  If the value of the location attribute cannot be mapped to the accessPoint value then the WSDL Implementation Document approach must be used. See Appendix A for further information.

·         The URLType attribute of the accessPoint MUST correspond to the transport protocol associated with the URL, or "other" if none of the defined values of the attribute are appropriate.

2.5                 Differences in mapping WSDL 1.1 in UDDI V3

This section describes the differences in the UDDI V3 view of the model that are a consequence of mandatory items in the UDDI V3 Specification.

2.5.1            Mandatory Differences

The mandatory differences are:

1. Entities will have V3 keys rather than V2 keys.
2. An accessPoint has a useType attribute rather than a URLType attribute.

2.5.2            Comparison to wsdlDeployment in UDDI V3 Specification

The UDDI V3 specification includes support for wsdlDeployment, which appears as both a value for the useType attribute of an accessPoint and as a categorization of a bindingTemplate.  Use of wsdlDeployment is not compatible with this Technical Note as it assumes that no modeling of the WSDL is performed, nothing is known about the WSDL other than its URL.

Consider the following WSDL sample based on the WSDL document presented in the WSDL 1.1 specification.[5] This example shows how this one WSDL document is decomposed into two tModels (one for the portType and one for the binding) and one businessService with one bindingTemplate. It then shows the kinds of UDDI API queries that can be used for the purpose of discovery. 

3.1                 WSDL Sample

Note that this WSDL document has one portType, one binding, one service, and one port. As such, this sample represents the simplest WSDL document. Also note that the location of this WSDL is at http://location/sample.wsdl.

3.2                 UDDI V2 Model

3.2.1            UDDI portType tModel

The WSDL portType entity maps to a tModel. The tModel name is the same as the WSDL portType local name. The tModel contains a categoryBag that specifies the WSDL namespace, and it indicates that the tModel is of type "portType". The overviewDoc provides a pointer to the WSDL document.

3.2.2            UDDI binding tModel

The WSDL binding entity maps to a tModel. The tModel name is the same as the WSDL binding local name. The tModel contains a categoryBag that specifies the WSDL namespace, it indicates that the tModel is of type "binding", it supplies a pointer to the portType tModel, and it indicates what protocols are supported by the binding. The wsdlSpec keyedReference ensures that users can find the tModel using the conventions defined in the Version 1 Best Practice. The overviewDoc provides a pointer to the WSDL document.

3.2.3            UDDI businessService and bindingTemplate

The WSDL service entity maps to a businessService, and the WSDL port entity maps to a bindingTemplate. The businessService name should be a human-readable name. The businessService contains a categoryBag that indicates that this service represents a WSDL service, and it specifies the WSDL namespace and WSDL service local name. The bindingTemplate specifies the endpoint of the service, and it contains a set of tModelInstanceDetails. The first tModelInstanceInfo indicates that the service implements the StockQuoteSoapBinding and provides the WSDL port local name. The second tModelInstanceInfo indicates that the service implements the StockQuotePortType.

3.3                 Sample V2 Queries

This section shows how to perform various UDDI V2 queries given the model of the example.

3.3.1            Find tModel for portType name

Find the portType tModel for StockQuotePortType in the namespace http://example.com/stockquote/.

This should return the tModelKey uuid:e8cf1163-8234-4b35-865f-94a7322e40c3.

3.3.2            Find bindings for portType

Find all bindings for StockQuotePortType.

This should return the tModelKey uuid:49662926-f4a5-4ba5-b8d0-32ab388dadda.

3.3.3            Find Implementations of portType

Find all implementations of StockQuotePortType.

Because the serviceKey attribute is required in the find_binding call in the UDDI V2 API, it is not possible to find all implementations of a portType with a single call.  A find_service call must be made first to get the keys of all services that contain a bindingTemplate that references the portType, then either the details of each such service must be retrieved with a get_serviceDetail call and the appropriate bindingTemplate looked for among the bindingTemplates of the service, or a find_binding call must be made for each service, with the serviceKey attribute set accordingly.  The following example shows the use of a find_binding call.

This first call gets the list of services that have a bindingTemplate that references the portType.

This should return the serviceKey 102b114a-52e0-4af4-a292-02700da543d4.

Now the second call is made to find the appropriate bindings of this particular service.

This should return the bindingKey f793c521-0daf-434c-8700-0e32da232e74.

3.3.4            Find implementations of binding

Find all implementations of StockQuoteSoapBinding.

This is very similar to the previous example, except that the tModelBag contains the key of the binding tModel rather than the portType tModel.

3.3.5            Find SOAP Implementations of portType

Find all implementations of StockQuotePortType that support SOAP.

At least three queries are needed.  The first query returns all the binding tModels that reference the portType tModel and that are categorized with SOAP.

What happens next depends on whether or not other criteria are also required in the overall query.

3.3.5.1      No Other Criteria

In this case, at least two other queries are required, as in the example above of finding implementations of a single binding.  The first of these is a find_service call which must include the "orAllKeys" findQualifier[6] and a tModelBag must be supplied which contains all the binding tModel keys returned by the first query.  This will return the list of services that have a bindingTemplate that references at least one of the binding tModels.

Finally, for each such service, either get_serviceDetail or find_binding must be called.

3.3.5.2      Other Criteria

In this case also, at least two other queries are required, depending on the number of binding tModels and services found.  For each binding tModel a find_service query is required and the default of "andAllKeys" must be used as the other criteria will also be applied to this query.  This will return the list of services that have a bindingTemplate that references the particular binding tModel and which also satisfies the other criteria.

Finally, for each such service, either get_serviceDetail or find_binding must be called, and again the other criteria must be applied.

3.3.6            Find SOAP/HTTP Implementations of portType

This is similar to the previous case except that the first query must also include a category for the HTTP transport in addition to the SOAP protocol.

3.3.7            Find the portType of a binding

The portType of a binding is contained in the categoryBag of the binding tModel. No query is required once the tModel of the binding has been obtained. The keyValue of the keyedReference with tModelKey="uuid:082b0851-25d8-303c-b332-f24a6d53e38e" contains the portType tModelKey.

3.3.8            Find the businessService for a WSDL service

Find the businessService for StockQuoteService in the namespace http://example.com/stockquote/.

This should return the serviceKey 102b114a-52e0-4af4-a292-02700da543d4.

3.4                 Sample V3 Queries

This section contains some of the sample queries from the previous section rewritten to use new features of the UDDI V3 API.  The other queries are not significantly different.  The entity keys shown assume that the V2 model was migrated to V3 by a root registry.

3.4.1            Find Implementations of portType

As serviceKey is optional for find_binding in the UDDI V3 API, it is possible to implement this with a single query:

This should return the bindingKey uddi:f793c521-0daf-434c-8700-0e32da232e74.

3.4.2            Find SOAP Implementations of portType

3.4.2.1      No Other Criteria

As serviceKey is optional for find_binding in the UDDI V3 API, and it is possible to embed a find_tModel call, it is possible to implement this with a single query:

This should return the bindingKey uddi:f793c521-0daf-434c-8700-0e32da232e74.

 

4.1                 Normative

[RFC2119]               S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, IETF RFC 2119, March 1997. Available at http://www.ietf.org/rfc/rfc2119.txt.

[1]                          Using WSDL in a UDDI Registry 1.08. Available at http://www.oasis-open.org/committees/uddi-spec/doc/bp/uddi-spec-tc-bp-using-wsdl-v108-20021110.pdf

[2]                          Web Services Description Language (WSDL) 1.1, March 15, 2000. Available at http://www.w3.org/TR/wsdl

[3]                          UDDI Version 2.03 Data Structure Reference, July 7, 2002. Available at http://uddi.org/pubs/DataStructure-V2.03-Published-20020719.pdf.

[4]                          UDDI Version 3.0 Published Specification, 19 July 2002. Available at http://www.uddi.org/pubs/uddi-v3.00-published-20020719.pdf.

[5]                          XPointer xpointer() Scheme, W3C Working Draft, 10 July 2002.  Available at http://www.w3.org/TR/2002/WD-xptr-xpointer-20020710/

 

There are multiple reasons why it may be desirable to support an external WSDL Implementation Document, among which are the following:

1. There are extensibility elements defined for the wsdl:service.
2. There is a wsdl:documentation element for a wsdl:port.
3. The address of a port may not be representable as a uddi:accessPoint value.
4. The authoritative source of the address is desired to be the WSDL document rather than UDDI.

The approach described here assumes that if any one of these reasons leads to the use of an external WSDL Deployment Document then the entire mapping described in this section is used.

There are two additional necessary pieces of information that must be captured to use external WSDL Implementation Documents:

1. The URL of the WSDL Implementation Document.
2. An indication that the port address must be obtained from the WSDL Implementation Document.

A.1 Capturing The URL

If an external WSDL Implementation Document is being used then the URL of this document must be used as the accessPoint value of each and every port of each and every service.

A.2 Obtaining the Port Address from WSDL

If a WSDL Implementation Document is being used then the bindingTemplate MUST contain sufficient information to identify the port address in the WSDL Implementation Document.  The mapping described here MUST be used instead of the mapping defined in section 2.4.5.

In all cases where a WSDL Implementation Document is used, the URLType attribute of the accessPoint corresponding to each port MUST be "other", and the value of the accessPoint MUST be the URL of the WSDL Implementation Document.

The bindingTemplate MUST contain a tModelInstanceInfo element with a tModelKey of the WSDL Address tModel. This tModelInstanceInfo element, in combination with the protocol and transport information from the binding tModel, provides the necessary information to locate and interpret the endpoint address.

A.3 Querying Services that use a WSDL Implementation Document

It is possible to query the services that have a WSDL Implementation Document by querying specifying the tModelKey of the WSDL Address tModel.

This Technical Note introduces a number of canonical tModels that are used to represent WSDL metadata and relationships. These tModels are defined here.

B.1 WSDL Entity Type tModel

B.1.1 Design Goals

This mapping uses a number of UDDI entities to represent the various entities within a WSDL document. A mechanism is required to indicate what type of WSDL entity is being described by each UDDI entity. The WSDL Entity Type tModel provides a typing system for this purpose. This category system is used to indicate that a UDDI entity represents a particular type of WSDL entity.

B.1.2 Definition

Name:                    uddi-org:wsdl:types               

Description:           WSDL Type Category System

V3 format key:        uddi:uddi.org:wsdl:types

V1,V2 format key:   uuid:6e090afa-33e5-36eb-81b7-1ca18373f457

Categorization:       categorization

Checked:                no

B.1.2.1 V2 tModel Structure

B.1.3 Valid Values

While this is an unchecked category system, there are only four values that should be used with this category system:

 

B.1.4 Example of Use

A V2 tModel representing a portType would have a categoryBag representing its type:

B.2 XML Namespace tModel

B.2.1 Design Goals

A namespace provides necessary qualifying information about a technical concept or model. The XML Namespace tModel provides a mechanism to associate a namespace with a UDDI entity. This category system describes a UDDI entity by specifying the target namespace of the description file (i.e., a WSDL document or XML Schema file) that describes the entity. More than one tModel might be categorized with the same namespace – in fact, this mapping would be quite common, as many WSDL documents use a common target namespace for wsdl:portType, wsdl:binding, and wsdl:service elements. 

B.2.2 Definition

Name:                    uddi-org:xml:namespace

Description:           A category system used to indicate namespaces

V3 format key:        uddi:uddi.org:xml:namespace

V1, V2 format key:  uuid:d01987d1-ab2e-3013-9be2-2a66eb99d824

Categorization:       categorization

Checked:                no

B.2.2.1 V2 tModel Structure

B.2.3 Valid Values

The values used in this category system are namespaces of type "anyURI". The content of keyValue in a keyedReference that refers to this tModel is the target namespace of the WSDL document that describes the WSDL entity described by the UDDI entity.

B.2.4 Example of Use

A namespace keyedReference would be as follows:

B.3 XML Local Name tModel

B.3.1 Design Goals

Each WSDL entity is identified by its name attribute, and this identification information needs to be captured in the mapped UDDI entities. In the case of wsdl:portType and wsdl:binding, the name attribute is mapped to the uddi:tModel name element. However, it isn’t always appropriate to map the wsdl:service name attribute to the name element of the businessService, and, in the case of wsdl:port, the bindingTemplate entity does not have a name element. The XML Local Name tModel provides a mechanism to indicate the name attribute for the uddi:businessService. 

 

B.3.2 Definition

Name:                    uddi-org:xml:localName

Description:           A category system used to indicate XML local names

V3 format key:        uddi:uddi.org:xml:localname

V1,V2 format key:   uuid:2ec65201-9109-3919-9bec-c9dbefcaccf6

Categorization:       categorization

Checked:                no   

B.3.2.1 V2 tModel Structure

B.3.3 Valid Values

The values used in this category system are XML local names. The content of keyValue in a keyedReference that refers to this tModel is equal to the name attribute of the WSDL entity described by the UDDI entity.

B.3.4 Example of Use

A local name keyedReference would be as follows:

B.4 WSDL portType Reference tModel

B.4.1 Design Goals

WSDL entities exhibit many relationships. Specifically, a wsdl:port describes an implementation of a wsdl:binding, and a wsdl:binding describes a binding of a particular wsdl:portType. These same relationships must be expressed in the UDDI mapping. UDDI provides a built-in mechanism, via the tModelInstanceInfo structure, to associate a bindingTemplate with a tModel. But UDDI does not provide a built-in mechanism to describe a relationship between two tModels. The WSDL portType Reference category system provides a mechanism to indicate that a UDDI entity has a relationship with a certain wsdl:portType tModel. This can be applied, for example, to indicate that a wsdl:binding tModel is a binding of a specific wsdl:portType tModel.

B.4.2 Definition

Name:                    uddi-org:wsdl:portTypeReference

Description:           A category system used to reference a wsdl:portType tModel

V3 format key:        uddi:uddi.org:wsdl:porttypereference    

V1,V2 format key:   uuid:082b0851-25d8-303c-b332-f24a6d53e38e

Categorization:       categorization 

Checked:                yes

B.4.2.1 V2 tModel Structure

B.4.3 Valid Values

Valid values for this category system are tModelKeys. The content of the keyValue attribute in a keyedReference that refers to this tModel is the tModelKey of the wsdl:portType tModel being referenced.

As the valid values are entity keys the V3 version of the tModel representing this category system must be categorized with the uddi:uddi.org:categorization:entitykeyvalues category system, with a keyValue of tModelKey.

B.4.4 Example of Use

One would add the following keyedReference to signify that a wsdl:binding implements a specific portType:

Note that the keyValue is a tModelKey, which, if queried for using get_tModelDetail, would return the tModel that represents the portType.

B.5 SOAP Protocol tModel

B.5.1 Design Goals

Web services can support a wide variety of protocols. Users looking for Web services may want to search for Web services that support a specific protocol. The SOAP Protocol tModel can be used to indicate that a Web service supports the SOAP 1.1 protocol. This tModel correlates to the http://schemas.xmlsoap.org/wsdl/soap/ namespace identified in the WSDL Specification.

B.5.2 Definition

Name:                    uddi-org:protocol:soap                 

Description:           A tModel that represents the SOAP 1.1 protocol          

V3 format key:        uddi:uddi.org:protocol:soap  

V1,V2 format key:   uuid:aa254698-93de-3870-8df3-a5c075d64a0e

Categorization:       protocol   

B.5.2.1 tModel Structure

B.5.3 Example of Use

The SOAP Protocol tModel is used to categorise a binding tModel that corresponds to a wsdl:binding that supports the SOAP 1.1 protocol.

B.6 HTTP Protocol tModel

B.6.1 Design Goals

Web services can support a wide variety of protocols. Users looking for Web services may want to search for Web services that support a specific protocol. The HTTP Protocol tModel can be used to indicate that a Web service supports the HTTP protocol. Note that this tModel is different from the HTTP Transport tModel. This tModel represents a protocol; for example, it represents the http://schemas.xmlsoap.org/wsdl/http/ namespace in the WSDL specification. The HTTP Transport tModel represents a transport.

B.6.2 Definition

Name:                    uddi-org:protocol:http                   

Description:           A tModel that represents the HTTP protocol          

V3 format key:        uddi:uddi.org:protocol:http

V1,V2 format key:   uuid:6e10b91b-babc-3442-b8fc-5a3c8fde0794

Categorization:       protocol   

B.6.2.1 V2 tModel Structure

B.6.3 Example of Use

The HTTP Protocol tModel is used to categorise a binding tModel that corresponds to a wsdl:binding that supports the HTTP protocol.  

B.7 Protocol Categorization

B.7.1 Design Goals

A Web service may communicate using a variety of protocols. A WSDL binding binds a portType to a specific protocol. A user may wish to search for bindings that implement a specific protocol. The Protocol Categorization tModel provides a mechanism to capture this protocol information in the UDDI binding tModel.

B.7.2 Definition

Name:                    uddi-org:wsdl:categorization:protocol

Description:           Category system used to describe the protocol supported by a wsdl:binding.    

V3 format key:        uddi:uddi.org:wsdl:categorization:protocol

V1,V2 format key:   uuid:4dc74177-7806-34d9-aecd-33c57dc3a865

Categorization:       categorization

Checked:                yes 

B.7.2.1 V2 tModel Structure

B.7.3 Valid Values

Valid values for this category system are tModelKeys. The content of the keyValue attribute in a keyedReference that refers to this tModel is the tModelKey of the tModel that represents a protocol.  The protocol tModel SHOULD be classified as "protocol" in the uddi-org:types categorization scheme.

As the valid values are entity keys the V3 version of the tModel representing this category system must be categorized with the uddi:uddi.org:categorization:entitykeyvalues category system, with a keyValue of tModelKey.

B.7.4 Example of Use

The Protocol category scheme is used to indicate the protocol that a binding supports.  

B.8 Transport Categorization

B.8.1 Design Goals

A Web service may communicate using a variety of transports. A WSDL binding binds a portType to a specific transport protocol. A user may wish to search for bindings that implement a specific transport protocol. The Transport Categorization tModel provides a mechanism to capture this transport information in the UDDI binding tModel.

B.8.2 Definition

Name:                    uddi-org:wsdl:categorization:transport

Description:           Category system used to describe the transport supported by a wsdl:binding.    

V3 format key:        uddi:uddi.org:wsdl:categorization:transport

V1,V2 format key:   uuid:e5c43936-86e4-37bf-8196-1d04b35c0099

Categorization:       categorization

Checked:                yes 

B.8.2.1 V2 tModel Structure

B.8.3 Valid Values

Valid values for this category system are tModelKeys. The content of the keyValue attribute in a keyedReference that refers to this tModel is the tModelKey of the tModel that represents a transport.  The transport tModel SHOULD be classified as "transport" in the uddi-org:types categorization scheme.

As the valid values are entity keys the V3 version of the tModel representing this category system must be categorized with the uddi:uddi.org:categorization:entitykeyvalues category system, with a keyValue of tModelKey

B.8.4 Example of Use

The Transport category system is used to indicate the transport that a binding supports.  

B.9 WSDL Address tModel

B.9.1 Design Goals

A service provider may not want to specify the address of a service port in the uddi:accessPoint element and instead require the user to retrieve a WSDL document to obtain the service address. UDDI V2 does not provide a built-in mechanism to indicate that the endpoint address should be obtained from a WSDL document. This document describes an approach to provide a mechanism using existing UDDI V2 features.  This approach requires that the bindingTemplate indicate that the WSDL document must be retrieved to obtain the address information.  The WSDL Address tModel provides such a mechanism. A V2 bindingTemplate includes a tModelInstanceInfo element that references this tModel to indicate that the address information must be retrieved from the WSDL document.

B.9.2 Definition

Name:                    uddi-org:wsdl:address

Description:           A tModel used to indicate the WSDL address option

V3 format key:        uddi:uddi.org:wsdl:address

V1,V2 format key:   uuid:ad61de98-4db8-31b2-a299-a2373dc97212

Categorization:       none

B.9.2.1 V2 tModel Structure

B.9.3 Valid Values

There are no valid values associated with this tModel, it is simply a marker.

B.9.4 Example of Use

If a service provider requires the user to retrieve the service endpoint from a WSDL document rather than from the UDDI bindingTemplate, the accessPoint element must have a value of "WSDL" and a URLType attribute value of "other":

C.1 XPointer Syntax

In this mapping of WSDL to UDDI, a UDDI entity describes a particular element within a WSDL document. The particular WSDL element described SHOULD be determined by using the metadata contained within the entity’s categoryBag, and either the UDDI entity’s name or the instanceParms value specified in the tModelInstanceInfo that relates to the binding that a port implements. Alternatively, the overviewURL value MAY contain a fragment identifier that identifies the particular WSDL element.

As the WSDL 1.1 schema does not allow for id attributes on WSDL elements, we cannot simply use a fragment identifier of the form #foo.

If the optional fragment identifier is used, the syntax defined by XPointer [5] SHOULD be used for the fragment identifier.  It should be noted that at the time of writing this Technical Note, XPointer is a set of Working Draft documents and is therefore subject to change.

C.1.1 Example of Use

Referring to the WSDL Sample in Section 3.1, the StockQuotePortType tModel may reference the wsdl:portType element directly from the overviewURL using XPointer syntax.

 

The following individuals were members of the committee during the development of this technical note:

Andrew Hately, IBM

Anne Manes

Sam Lee, Oracle

Alok Srivastava, Oracle

Claus von Riegen, SAP

 

Rev	Date	By Whom	What
20021022	22 Oct 2002	John Colgrave and Karsten Januszewski	First draft of V2.0 TN
20021114	14 Nov 2002	Tony Rogers and Anne Thomas Manes	Second draft of V2.0 TN for TC discussion
20030319	19 Mar 2003	John Colgrave, Anne Thomas Manes and Tony Rogers	Final draft of V2.0 TN for TC review
20030627	27 June 2003	John Colgrave	Version for TC vote
20031104	04 November 2003 Version 2.0.1	John Colgrave	Changes to tModel names to make them consistent.
20040601	1 June 2004	Luc Clément Tony Rogers	Changes to tModel content to make them consistent. Removal of section 2.5.2 (of the 20031104 version) describing an optional v3 mapping. Removal of Footnote 1 (of the 20031104 version). Clarified that a keyedReference to the XML Namespace category system MUST only be made if the definitions element has a target namespace, otherwise if there is no target namespace, the reference MUST NOT be made. See sections 2.4.1, 2.4.2 and 2.4.3.
20040631	31 June 2004 Version 2.0.2	Luc Clément John Colgrave Claus von Riegen	Generalization of the WSDL portType Reference tModel Case-folding of v3 entity keys for consistency.

 

OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS's procedures with respect to rights in OASIS specifications can be found at the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification, can be obtained from the OASIS Executive Director.

OASIS invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to implement this specification. Please address the information to the OASIS Executive Director.

Copyright  © OASIS Open 2004. All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself does not be modified in any way, such as by removing the copyright notice or references to OASIS, except as needed for the purpose of developing OASIS specifications, in which case the procedures for copyrights defined in the OASIS Intellectual Property Rights document must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.