|
|
UDDI Spec TC |
Technical Note
Using WSDL in a UDDI Registry, Version 2.0.2
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).
Table of Contents
1.2 Relationship to Version 1 Best Practice
2 Mapping Two Data Models: WSDL & UDDI
2.2.2 businessService & bindingTemplate
2.3.2 Comparison to Version 1 Mapping
2.3.5 Support for Multiple UDDI API Versions
2.3.6 References to WSDL Components
2.3.7 WSDL Extensibility Elements
2.3.8 Support for WSDL Implementation Documents
2.4 Mapping WSDL 1.1 in UDDI V2
2.4.1 wsdl:portType -> uddi:tModel
2.4.2 wsdl:binding -> uddi:tModel
2.4.3 wsdl:service -> uddi:businessService
2.4.4 wsdl:port -> uddi:bindingTemplate
2.4.5 wsdl:port Address Extensions -> uddi:bindingTemplate
2.5 Differences in mapping WSDL 1.1 in UDDI V3
2.5.2 Comparison to wsdlDeployment in UDDI V3 Specification
3.2.3 UDDI businessService and bindingTemplate
3.3.1 Find tModel for portType name
3.3.2 Find bindings for portType
3.3.3 Find Implementations of portType
3.3.4 Find implementations of binding
3.3.5 Find SOAP Implementations of portType
3.3.6 Find SOAP/HTTP Implementations of portType.
3.3.7 Find the portType of a binding
3.3.8 Find the businessService for a WSDL service.
3.4.1 Find Implementations of portType
3.4.2 Find SOAP Implementations of portType
A External WSDL Implementation Documents
A.2 Obtaining the Port Address from WSDL
A.3 Querying Services that use a WSDL Implementation Document
B.4 WSDL portType Reference tModel
C Using XPointer in overviewURL
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:
- 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 mapping described in the Using WSDL in a UDDI Registry, Version 1.08 [1] Best Practice document
- To provide a consistent mapping for UDDI Version 2 and UDDI Version 3
- 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:
- The information in the UDDI model is the authoritative information and there is no reference to a WSDL Implementation Document.
- 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:
- A keyedReference with a tModelKey of the WSDL Entity Type category system and a keyValue of "binding".
- 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.
- A keyedReference with a tModelKey of the UDDI Types category system and a keyValue of "wsdlSpec" for backward compatibility[1].
- 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:
- Protocol Categorization
- 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:
- A keyedReference with a tModelKey of the WSDL Entity Type category system and a keyValue of "service".
- 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:
- 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.
- 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:
- Entities will have V3 keys rather than V2 keys.
- 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
<?xml version="1.0" encoding="utf-8"?>
<definitions
name="StockQuote"
targetNamespace="http://example.com/stockquote/"
xmlns:tns="http://example.com/stockquote/"
xmlns:xsd1="http://example.com/stockquote/schema/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns="http://schemas.xmlsoap.org/wsdl/">
<types>
<schema
targetNamespace="http://example.com/stockquote/schema/"
xmlns="http://www.w3.org/2001/XMLSchema">
<element name="TradePriceRequest">
<complexType>
<all>
<element name="tickerSymbol" type="string"/>
</all>
</complexType>
</element>
<element name="TradePrice">
<complexType>
<all>
<element name="price" type="float"/>
</all>
</complexType>
</element>
</schema>
</types>
<message name="GetLastTradePriceInput">
<part name="body" element="xsd1:TradePriceRequest"/>
</message>
<message na