UDDI Spec TC

UDDI Other Core tModels, Version 2.04

11 December 2002

Document identifier:

UDDI_CoreOther_tModels

Location:

http://uddi.org/taxonomies/UDDI_CoreOther_tModels.htm

Editors:

Toufic Boubez

Luc Clément, Microsoft

Abstract:

This document contains tModel definitions used to help register UDDI businessServices using leading industry encoding schemes and standard protocols.

Status:

This document is updated periodically on no particular schedule.

Committee members should send comments on this Committee Specification to the uddi-spec@lists.oasis-open.org list. Others should subscribe to and send comments to the uddi-spec-comment@lists.oasis-open.org list. To subscribe, send an email message to uddi-spec-comment-request@lists.oasis-open.org with the word "subscribe" as the body of the message.

For information on whether any intellectual property claims have been disclosed that may be essential to implementing this Committee Specification, 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/).

Copyrights

Copyright © 2001-2002 by Accenture, Ariba, Inc., Commerce One, Inc., Fujitsu Limited, Hewlett-Packard Company, i2 Technologies, Inc., Intel Corporation, International Business Machines Corporation, Microsoft Corporation, Oracle Corporation, SAP AG, Sun Microsystems, Inc., and VeriSign, Inc. All Rights Reserved.

Table of Contents

1 UDDI Homepage Specification. 3

2 UDDI HTTP Transport 5

3 UDDI SMTP Transport 6

4 UDDI FTP Transport 8

5 UDDI Fax Protocol 9

6 UDDI Telephone Specification. 11

7 References. 13

8 Notices. 13

1 UDDI Homepage Specification

1.1 Introduction

In UDDI, tModels are used to establish the existence of a variety of concepts and to point to their technical definitions. tModels of the specification sort are referenced by service bindings to describe the technical fingerprint of the business service. The Homepage specification tModel establishes the concept of a home page service to enable businesses to register their home pages in UDDI in an easily identifiable and retrievable fashion.

1.2 Design Goals

The design goal for the Homepage tModel is to standardize discovery of home pages within UDDI. Inquiries can be performed to find business homepages. These inquiries can be further refined to include categorization selection criteria, thereby only locating home pages for a particular industry, for example.

1.3 tModel Definition

This tModel is used as the bindingTemplate fingerprint for a web home page reference. bindingTemplates should refer to this tModel if they represent home page service implementations.

1.3.1 tModel:

Name: uddi-org:homepage

Description: HTTP Web Home Page URL

tModel UUID: uuid:4CEC1CEF-1F68-4B23-8CB7-8BAA763AEB89

Categorization: specification

1.3.1.1 tModel Structure

<name>uddi-org:homepage</name>

This tModel is used as the bindingTemplate fingerprint for a web home page reference.

</description>

http://www.uddi.org/taxonomies/UDDI_CoreOther_tModels.htm#Homepage

</overviewURL>

</overviewDoc>

<keyedReference tModelKey="uuid:C1ACF26D-9672-4404-9D70-39B756E62AB4"

keyName="tModelType"

keyValue="specification"/>

</categoryBag>

</tModel>

1.4 Example of Use

The following is a typical bindingTemplate that references the Homepage tModel:

<accessPoint URLType="http">http://www.myco.example/index.html</accessPoint>

</tModelInstanceDetails>

</bindingTemplate>

2 UDDI HTTP Transport

2.1 Introduction

In UDDI, tModels are used to establish the existence of a variety of concepts and to point to their technical definitions. tModels of the transport sort are referenced by service bindings to describe the type of transport used to invoke the service, either when other parts of the technical fingerprint (other tModels referenced in the same bindingTemplate) are silent or ambiguous with respect to the transport used by the particular service binding, or when the service provider wants to explicitly call out the transport in the technical fingerprint so as to enable proper discovery. Transport-type tModels are frequently coupled with other tModels that describe more completely what the service does. For very simple services, a transport tModel may be the only tModel referenced in a bindingTemplate. The HTTP Transport tModel provides a means for designating those services that are invoked by performing an HTTP GET on the accessPoint in the bindingTemplate.

2.2 Design Goals

The HTTP Transport tModel is provided to enable discovery of services that are invoked by performing an HTTP GET on the accessPoint in the bindingTemplate, to mix-in the applicable transport when other parts of the technical fingerprint are ambiguous or silent with respect to the transport to use, and to enable simple services that are accessed through HTTP to have a technical fingerprint when they might otherwise not have a tModel to reference in their bindingTemplates.

2.3 tModel Definition

This tModel is used to describe a web service that is invoked through a web browser and/or the http protocol.

2.3.1 tModel:

Name: uddi-org:http

Description: An HTTP or web browser-based web service

tModel UUID: uuid:68DE9E80-AD09-469D-8A37-088422BFBC36

Categorization: transport

2.3.1.1 tModel Structure

<description xml:lang="en">An http or web browser based web service</description>

This tModel is used to describe a web service that is invoked through a web

browser and/or the http protocol.

</description>

http://www.uddi.org/taxonomies/UDDI_CoreOther_tModels.htm#overHTTP

</overviewURL>

</overviewDoc>

<keyedReference tModelKey="uuid:C1ACF26D-9672-4404-9D70-39B756E62AB4"

keyName="tModelType"

keyValue="transport"/>

</categoryBag>

</tModel>

2.4 Example of Use

The following is a typical bindingTemplate for a simple service that references the HTTP Transport tModel:

<description xml:lang="en">Buy from Bigfoot Breweries over the Web</description>

<accessPoint URLType="http">http://www.bigfootbreweries.example/shop.html</accessPoint>

</tModelInstanceDetails>

</bindingTemplate>

The next example shows a bindingTemplate for a service whose technical fingerprint (the first tModel referenced) specifies two alternative access techniques, of which HTTP is one:

<description xml:lang="en">Obtain financing</description>

<accessPoint URLType="http">http://www.consolidatedholdings.example/finance.html</accessPoint>

<!-- The first tModel describes a technical interface (to obtain financing) which

includes multiple binding descriptions. HTTP is one such supported binding. -->

</tModelInstanceDetails>

</tModelInstanceDetails>

</bindingTemplate>

3 UDDI SMTP Transport

3.1 Introduction

In UDDI, tModels are used to establish the existence of a variety of concepts and to point to their technical definitions. tModels of the transport sort are referenced by service bindings to describe the type of transport used to invoke the service, either when other parts of the technical fingerprint (other tModels referenced in the same bindingTemplate) are silent or ambiguous with respect to the transport used by the particular service binding, or when the service provider wants to explicitly call out the transport in the technical fingerprint so as to enable proper discovery. Transport-type tModels are frequently coupled with other tModels that describe more completely what the service does. For very simple services, a transport tModel may be the only tModel referenced in a bindingTemplate. The SMTP Transport tModel provides a means for designating those services that are invoked by sending an eMail to the accessPoint in the bindingTemplate.

3.2 Design Goals

The SMTP Transport tModel is provided to enable discovery of services that are invoked by sending an eMail to the address in the accessPoint element of the bindingTemplate, to mix-in the applicable transport when other parts of the technical fingerprint are ambiguous or silent with respect to the transport to use, and to enable simple services that are accessed through eMail to have a technical fingerprint when they might otherwise not have a tModel to reference in their bindingTemplates.

3.3 tModel Definition

This tModel is used to describe a web service that is invoked through SMTP eMail transmissions. These transmissions may be either between people or applications.

3.3.1 tModel:

Name: uddi-org:smtp

Description: E-mail based web service

tModel UUID: uuid:93335D49-3EFB-48A0-ACEA-EA102B60DDC6

Categorization: transport

3.3.1.1 tModel Structure

<description xml:lang="en">E-mail based web service</description>

This tModel is used to describe a web service that is invoked through

SMTP email transmissions. These transmissions may be either between

people or applications.

</description>

http://www.uddi.org/taxonomies/UDDI_CoreOther_tModels.htm#overSMTP

</overviewURL>

</overviewDoc>

<keyedReference tModelKey="uuid:C1ACF26D-9672-4404-9D70-39B756E62AB4"

keyName="tModelType"

keyValue="transport"/>

</categoryBag>

</tModel>

3.4 Example of Use

The following is a typical bindingTemplate that references the SMTP Transport tModel:

<description xml:lang="en">Send eMail to buy from Island Trading</description>

<accessPoint URLType="mailto">mailto:order@islandtrading.example</accessPoint>

</tModelInstanceDetails>

</bindingTemplate>

4 UDDI FTP Transport

4.1 Introduction

In UDDI, tModels are used to establish the existence of a variety of concepts and to point to their technical definitions. tModels of the transport sort are referenced by service bindings to describe the type of transport used to invoke the service, either when other parts of the technical fingerprint (other tModels referenced in the same bindingTemplate) are silent or ambiguous with respect to the transport used by the particular service binding, or when the service provider wants to explicitly call out the transport in the technical fingerprint so as to enable proper discovery. Transport-type tModels are frequently coupled with other tModels that describe more completely what the service does. For very simple services, a transport tModel may be the only tModel referenced in a bindingTemplate. The FTP Transport tModel provides a means for designating those services that are invoked using the File Transfer Protocol on the accessPoint in the bindingTemplate.

4.2 Design Goals

The FTP Transport tModel is provided to enable discovery of services that are invoked by performing an FTP on the address in the accessPoint element of the bindingTemplate, to mix-in the applicable transport when other parts of the technical fingerprint are ambiguous or silent with respect to the transport to use, and to enable simple services that are accessed using FTP to have a technical fingerprint when they might otherwise not have a tModel to reference in their bindingTemplates.

4.3 tModel Definition

This tModel is used to describe a web service that is invoked through file transfers via the FTP protocol.

4.3.1 tModel:

Name: uddi-org:ftp

Description: File Transfer Protocol (FTP) based web service

tModel UUID: uuid:5FCF5CD0-629A-4C50-8B16-F94E9CF2A674

Categorization: transport

4.3.1.1 tModel Structure

<description xml:lang="en">File transfer protocol (FTP) based web service</description>

This tModel is used to describe a web service that is invoked through file

transfers via the FTP protocol.

</description>

http://www.uddi.org/taxonomies/UDDI_CoreOther_tModels.htm#overFTP

</overviewURL>

</overviewDoc>

<keyedReference tModelKey="uuid:C1ACF26D-9672-4404-9D70-39B756E62AB4"

keyName="tModelType"

keyValue="transport"/>

</categoryBag>

</tModel>

4.4 Example of Use

The following is a typical bindingTemplate that references the FTP Transport tModel:

<description xml:lang="en">Obtain Island Trading product catalog using FTP</description>

<accessPoint URLType="ftp">ftp:islandtrading.example/catalog</accessPoint>

</tModelInstanceDetails>

</bindingTemplate>

5 UDDI Fax Protocol

5.1 Introduction

In UDDI, tModels are used to establish the existence of a variety of concepts and to point to their technical definitions. tModels of the protocol sort are referenced by service bindings to describe the type of protocol used to invoke the service, either when other parts of the technical fingerprint (other tModels referenced in the same bindingTemplate) are silent or ambiguous with respect to the protocol used by the particular service binding, or when the service provider wants to explicitly call out the protocol in the technical fingerprint so as to enable proper discovery. Protocol-type tModels are frequently coupled with other tModels that describe more completely what the service does. For very simple services, a protocol tModel may be the only tModel referenced in a bindingTemplate. The Fax Protocol tModel provides a means for designating those services that are invoked using a fax machine directed to the accessPoint (fax number) in the bindingTemplate.

5.2 Design Goals

The Fax Protocol tModel is provided to enable discovery of services that are invoked by sending a fax to the address in the accessPoint element of the bindingTemplate, to mix-in the applicable protocol when other parts of the technical fingerprint are ambiguous or silent with respect to the protocol to use, and to enable simple services that are accessed by sending a fax to have a technical fingerprint when they might otherwise not have a tModel to reference in their bindingTemplates.

5.3 tModel Definition

This tModel is used to describe a service that is invoked through fax transmissions. These transmissions may be either between people or applications.

5.3.1 tModel:

Name: uddi-org:fax

Description: Fax-based web service

tModel UUID: uuid:1A2B00BE-6E2C-42F5-875B-56F32686E0E7

Categorization: protocol

5.3.1.1 tModel Structure

<description xml:lang="en">Fax-based web service</description>

This tModel is used to describe a web service that is invoked through

fax transmissions. These transmissions may be either between people or applications.

</description>

http://www.uddi.org/taxonomies/UDDI_CoreOther_tModels.htm#overFAX

</overviewURL>

</overviewDoc>

<keyedReference tModelKey="uuid:C1ACF26D-9672-4404-9D70-39B756E62AB4"

keyName="tModelType"

keyValue="protocol"/>

</categoryBag>

</tModel>

5.4 Example of Use

The following is a typical bindingTemplate that references the Fax Protocol tModel:

<description xml:lang="en">Send facsimile to buy from Island Trading</description>

</tModelInstanceDetails>

</bindingTemplate>

6 UDDI Telephone Specification

6.1 Introduction

In UDDI, tModels are used to establish the existence of a variety of concepts and to point to their technical definitions. tModels of the specificaion sort are referenced by service bindings to describe all or part of the technical fingerprint that describes the service. The UDDI Telephone Specification tModel provides a means for designating those voice services that are invoked using a telephone that is directed to the telephone number in the accessPoint of the bindingTemplate. This tModel can be used when other parts of the technical fingerprint (other tModels referenced in the same bindingTemplate) are silent or ambiguous with respect to the manner in which the service is accessed, or when the service provider wants to explicitly call out the fact that a service is invoked over the telephone in the technical fingerprint so as to enable proper discovery. The Telephone Specification tModel is frequently coupled with other tModels that describe more completely what the service does. For very simple services, this tModel may be the only tModel referenced in a bindingTemplate.

6.2 Design Goals

The Telephone Specification tModel is provided to enable discovery of services that are accessed using voice with a telephone, to mix-in the voice over telephone access technique when other parts of the technical fingerprint are ambiguous or silent with respect to the way the service is accessed, and to enable simple services that are accessed by using a telephone to have a technical fingerprint when they might otherwise not have a tModel to reference in their bindingTemplates.

6.3 tModel Definition

This tModel is used to describe a service that is invoked through a telephone call and interaction by voice and/or touch-tone.

6.3.1 tModel:

Name: uddi-org:telephone

Description: Telephone based service

tModel UUID: uuid:38E12427-5536-4260-A6F9-B5B530E63A07

Categorization: specification

6.3.1.1 tModel Structure

<name>uddi-org:telephone</name>

<description xml:lang="en">Telephone based service</description>

This tModel is used to describe a service that is invoked through a telephone call

and interaction by voice and/or touch-tone.

</description>

http://www.uddi.org/taxonomies/UDDI_CoreOther_tModels.htm#overPhone

</overviewURL>

</overviewDoc>

<keyedReference tModelKey="uuid:C1ACF26D-9672-4404-9D70-39B756E62AB4"

keyName="tModelType"

keyValue="specification"/>

</categoryBag>

</tModel>

6.4 Example of Use

The following is a typical bindingTemplate that references the Telephone Specification tModel:

<description xml:lang="en">Buy from Island Trading over the phone</description>

</tModelInstanceDetails>

</bindingTemplate>

7 References

[1] "UDDI Version 2.0 API Specification", http://uddi.org/pubs/ProgrammersAPI_v2.htm

[2] " UDDI Version 2.0 API schema ", http://www.uddi.org/schema/uddi_v2.xsd

8 Notices

These UDDI Specifications (the "Documents") are provided by the companies named above ("Licensors") under the following license. By using and/or copying this Document, or the Document from which this statement is linked, you (the licensee) agree that you have read, understood, and will comply with the following terms and conditions:

Permission to copy, prepare derivative works based on, and distribute the contents of this Document, or the Document from which this statement is linked, and derivative works thereof, in any medium for any purpose and without fee or royalty under copyrights is hereby granted, provided that you include the following on ALL copies of the document, or portions thereof, that you use:

1. A link to the original document posted on uddi.org.

2. An attribution statement : "Copyright © 2000 - 2002 by Accenture, Ariba, Inc., Commerce One, Inc. Fujitsu Limited, Hewlett-Packard Company, i2 Technologies, Inc., Intel Corporation, International Business Machines Corporation, Microsoft Corporation, Oracle Corporation, SAP AG, Sun Microsystems, Inc., and VeriSign, Inc. All Rights Reserved."

If the Licensors own any patents or patent applications that may be required for implementing and using the specifications contained in the Document in products that comply with the specifications, upon written request, a non-exclusive license under such patents shall be granted on reasonable and non-discriminatory terms.

EXCEPT TO THE EXTENT PROHIBITED BY LOCAL LAW, THIS DOCUMENT (OR THE DOCUMENT TO WHICH THIS STATEMENT IS LINKED) IS PROVIDED "AS IS," AND LICENSORS MAKE NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, ACCURACY OF THE INFORMATIONAL CONTENT, NON-INFRINGEMENT, OR TITLE; THAT THE CONTENTS OF THE DOCUMENT ARE SUITABLE FOR ANY PURPOSE; NOR THAT THE IMPLEMENTATION OF SUCH CONTENTS WILL NOT INFRINGE ANY THIRD PARTY OR (WITH THE EXCEPTION OF THE RELEVANT PATENT LICENSE RIGHTS ACTUALLY GRANTED UNDER THE PRIOR PARAGRAPH) LICENSOR PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS. Some jurisdictions do not allow exclusions of implied warranties or conditions, so the above exclusion may not apply to you to the extent prohibited by local laws. You may have other rights that vary from country to country, state to state, or province to province.

EXCEPT TO THE EXTENT PROHIBITED BY LOCAL LAW, LICENSORS WILL NOT BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL, CONSEQUENTIAL DAMAGES, OR OTHER DAMAGES (INCLUDING LOST PROFIT, LOST DATA, OR DOWNTIME COSTS), ARISING OUT OF ANY USE, INABILITY TO USE, OR THE RESULTS OF USE OF THE DOCUMENT OR THE PERFORMANCE OR IMPLEMENTATION OF THE CONTENTS THEREOF, WHETHER BASED IN WARRANTY, CONTRACT, TORT, OR OTHER LEGAL THEORY, AND WHETHER OR NOT ANY LICENSOR WAS ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. Some jurisdictions do not allow the exclusion or limitation of liability for incidental or consequential damages, so the above limitation may not apply to you to the extent prohibited by local laws.

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.

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.