Understanding UDDI's tModel

Introduction: who should be interested in this article?

Recently I have been working on semantic Web and semantic Web services, this effort requires some fairly detailed understanding of UDDI data structures and APIs, especially its tModel concept. Reading some official documents about tModel's specification only made me even more confused: what exactly is tModel? Why do we need it? How do we use it? Googling this concept certainly produced tons of documents, but none of them seemed to provide a simple and clear answer.

It turns out the tModel concept is just like the XML namespace concept: it is not complex at all, yet it can be very confusing for quite a while. This article tries to present a clear picture about tModel. Now, here are the reasons that might interest you to continue reading:

• you want to have a clear understanding about tModels
• you need to expand the UDDI data structure to fit your special needs
• you want to study and develop semantic Web services

In the next several sections I will describe three different roles of tModel in the UDDI structure, based on my own understanding. I assume you have a good understanding of UDDI so this article is not a tutorial about UDDI. Please let me hear your comments if you really spend time reading it: I want to hear from you and learn from you, together, we make progress every day.

tModel Is Used to Represent Interfaces

Intuitively speaking, UDDI is an online "yellow book" that is used by both the service providers and service consumers. The service providers will register their Web services into UDDI, and service consumers will try to find the service descriptions from this online registry which will finally lead to the services that they desire.

The idea of "interface" in the world of UDDI is more or less similar to the concept of interface in the world of COM/DCOM, i.e., it is the "contract" that both the service provider and the service consumer will honor: the service provider promises to implement the Web service in such a way that if the consumer invokes the service by following this contract, his/her application will get what it expects.

All these being said, let us review the following most distinct feature of UDDI: when a service provider wants to register a Web service with UDDI, he/she must guarantee that this service implements an interface, and furthermore, this interface has to be already registered with UDDI.

Notice that the interface a Web service implements may or may not be defined by this service provider. For instance, some major airlines may get together and form a committee which will work out and publish (register) an interface in UDDI for querying the ticket price on a given date, time, and city pairs. This published interface will become the industrial standard, and the implementation work is left to be done by each specific airline. Each airline will then develop a Web service that implements this interface and also register the service with UDDI. In this case, the interface is not defined by the airline which implements it. Also, it is quite obvious that the life of a travel agent is now quite easy: although we have quite a few different airlines, there is only one querying interface he/she needs to worry about.

It may certainly be true that the Web service a given provider wants to register has no standard interface at all, in which case, the provider will have to first create and register an interface with UDDI. After this interface is registered, the service that implements it can then be developed and registered.

By now, one should be able to tell already how important an interface is in UDDI. But exactly how does an interface exist in UDDI? In what kind of "language" is the interface described? The answer gives the first big role of tModel: every single interface in UDDI is represented by a tModel.

An example seems to be appropriate at this point. Let us say that we want to create a Web service for CodeProject.com which will accept a String representing a person's name, and will return a non-negative integer indicating how many articles this person has submitted to CodeProject.com. This seems to be a fairly "special" service, so we assume there is no current "standard" for this service, i.e., there is no existing interface we can register our service against. Therefore, we need to create our own interface first.

By using the appropriate tools, we create and register with UDDI the interface we want, it is just a tModel which looks like the following:

----------------------------------------------------
        List-1. Example of tModel (interface)
----------------------------------------------------

<tModel tModelKey="uuid:5DD52389-B1A4-4fe7-B131-0F8EF73DD175">
   <name>this is the interface we created</name>
   <description xml:lang="en">interface for Web service 
                              answering num of submissions</description>
   <overviewDoc>
      <description xml:lang="en">The service's WSDL document</description>
      <overviewURL>http://www.codeproject.com/services/
                       interfaces/numOfSubmissions.wsdl</overviewURL>
   </overviewDoc>
</tModel>

This is it - a tModel that represents the interface of the Web service that we are going to develop and register, and it is really not complex at all. Let us take a closer look at it. The first thing we notice is that it has a UUID that is generated automatically and it is used as the unique ID when we reference this tModel. It also has a name, and a description (and in fact, other optional items, which we are not going to talk about here). The most important thing is, the real "interface" lies in the overviewURL tag: it points to the WSDL that is used to describe this Web service. In fact, you can point to any document which describes this Web service. However, a WSDL file will serve our purpose the best since it has enough information for the potential service consumers to invoke the service.

After we register the above interface, we can go ahead and develop the service that implements this interface and further register it into UDDI. This registration process creates a document which has a root element called businessEntity. Inside this element, the bindingTemplate tag is pointing to the above tModel by referencing its key. This is where the "contract" between the service provider and the interface is being established: this business entity provides a Web service that implements the given interface, which is represented by the tModel show in List-1.

Now assume that some application wants to invoke this service. It will first search within the bindingTemplate element to find out the service’s access point and the service’s interface ID, i.e., the tModelKey in List-1. The interface tModel is retrieved by using this key, and from this interface tModel, the WSDL document can then be located, which provides enough information to invoke the service.

This all sounds fine except one key point: how does the application find the right bindingTemplate element to search at the first place? Since the bindingTemplate element is a child element of businessEntity, our question is equivalent to "how does the application, or a developer, find the right businessEntity element at the first place?".

In real life, for a Web service that we desire, it is possible that we already know which company (businessEntity) has implemented it, so based on this knowledge and by using UDDI APIs, we are able to find the businessEntity first, then from there we find the interface information which leads us to the WSDL file. However, in many cases, we only know what kind of service we want and we have no idea which companies have implemented it. For cases like these, it might sound more feasible that one should first find the interface which matches the desired functionality, then from the interface one can find all the companies which have implemented this tModel.

This leads to another interesting question: how can one find the interface which matches the desired functionality easily? Study List-1, it is a tModel example. One can quickly realize that there is simply no (easy) way to find the desired interface - there is something missing and we need to add more information into it to help us find the desired one efficiently.

The current (but not that great) solution is to add categorization information into these interfaces (and other UDDI data structures) to make a given interface a member of one or more pre-defined categories, therefore one can find the desired ones based on some classification scheme.

The next question therefore is, how can we describe these classification schemes, i.e., what kind of constructs can we use to represent them so we can easily add them into tModels (and other data structures) which will make our search easier? The answer is probably not surprising at this point: use tModels to represent categorization!

Therefore, the second role of a tModel is to use it as a representation of a classification scheme as described in the next section.

tModel is Used as a Categorization Tool to Facilitate Discovery of Web Services

To facilitate the search for the desired interfaces, it turns out that we can use tModels to represent classification schemes - these tModels are pre-defined - and one can add these tModels as needed into the interface representation. Since the interface itself is represented by a tModel, it is then interesting to realize that we are in fact inserting a tModel (child) into a tModel (parent), but the parent tModel represents an interface, while the child tModel represents some classification schemes. By now, we start to appreciate the fact the tModel is a very flexible data structure which can be used to represent quite different entities.

If you go to this web site, you will find the "UDDI Core tModels": these are pre-defined/pre-registered tModels which represent classification information. For example, one of these tModels has a UUID that looks like this: "uuid:C1ACF26D-9672-4404-9D70-39B756E62AB4", with a name called wsdlSpec. This is a special categorization tModel and it is used to categorize a given interface (for example, List-1) as an interface definition of a WSDL-based Web service.

Again, look back to List-1, we know this interface is defined as a WSDL-based Web service interface. Therefore, we need to categorize it using the wsdlSpec tModel. By doing so, UDDI's search engine will be able to identify that this interface definition is for a WSDL-based Web service. List-2 shows the interface definition after we add the wsdlSpec tModel:

----------------------------------------------------
        List-2. Example of tModel (interface)
                with wsdlSpec tModel added
----------------------------------------------------

<tModel tModelKey="uuid:5DD52389-B1A4-4fe7-B131-0F8EF73DD175">
   <name>this is the interface we created</name>
   <description xml:lang="en">interface for Web service 
                   answering num of submissions</description>
   <overviewDoc>
      <description xml:lang="en">The service's WSDL document</description>
      <overviewURL>http://www.codeproject.com/services/
                      interfaces/numOfSubmissions.wsdl</overviewURL>
   </overviewDoc>
   <categoryBag>
      <keyedReference
         tModelKey="uuid:c1acf26d-9672-4404-9d70-39b756e62ab4"
         keyName="Specification for a web service described in WSDL"
         keyValue="wsdlSpec"/>
   </categoryBag>;
</tModel>

Looking at List-2, you will also notice that the newly added categorization information, namely, the wsdlSpec tModel is added into the categoryBad element using the keyedReference data structure, not to worry, this is just the syntax you need to follow when adding classification information into interfaces.

Now if some developer uses the UDDI APIs to search for "wsdlSpec", our interface definition will show up in the result list, since our interface is defined to point to a WSDL document for the Web service and we did add the correct categorization information into the interface definition. This developer can further examine our interface to see if this service will satisfy his/her needs.

Clearly, the above search will bring up quite a lot of interfaces, therefore, more classification information is needed for a more efficient search. One solution is to add more categorization information into the interface definition tModel. Let us again go here. Another pre-defined tModel with "uuid:c0b9fe13-179f-413d-8a5b-5004db8e5bb2" has a categorization called "On-Line Information Services". Since clearly our service is an on-line information service, we might as well add this categorization information into our interface to make it more specific. List-3 shows the final look of our interface.

----------------------------------------------------
        List-3. Example of tModel (interface)
                with wsdlSpec tModel added, and
                with more classification information
----------------------------------------------------

<tModel tModelKey="uuid:5DD52389-B1A4-4fe7-B131-0F8EF73DD175">
   <name>this is the interface we created</name>
   <description xml:lang="en">interface for Web service 
                              answering num of submissions</description>
   <overviewDoc>
      <description xml:lang="en">The service's WSDL document</description>
      <overviewURL>http://www.codeproject.com/services/
                       interfaces/numOfSubmissions.wsdl</overviewURL>
   </overviewDoc>
   <categoryBag>
      <keyedReference
         tModelKey="uuid:c1acf26d-9672-4404-9d70-39b756e62ab4"
         keyName="Specification for a web service described in WSDL"
         keyValue="wsdlSpec"/>
      <keyedReference
         tModelKey="uuid:c0b9fe13-179f-413d-8a5b-5004db8e5bb2"
         keyName="On-Line Information Services"
         keyValue="514191"/>
   </categoryBag>
</tModel>

Our interface now really takes some good shape. In this section, we explored the situation where tModels are used as classification tools to make the interface more specific therefore a more efficient search can be implemented by the search engine. Next, we are going to use tModels as namespaces - read on.

tModel Is Used As Namespace

Let us say some developer used some smart way to search the UDDI registry and he finally found our interface (List-3), and his next step is to decide whether the Web service that implements this interface is exactly the service he wants. By studying this interface, he cannot really make any decision: the information in this interface is too limited after all. He has to go to the WSDL file pointed to by this interface to do further investigation. Now the question is, can we kindly provide him with more information about exactly what this service does?

One thing we can do is to add some information in this interface to tell the potential users what inputs this service will require and what outputs this service will produce. This will give them some help deciding whether the service that implements this interface is the right one for them. We can implement this idea by again adding a keyedReference structure into the categoryBag element, see List-4.

----------------------------------------------------
        List-4. Example of tModel (interface)
                A more friendly interface
----------------------------------------------------

<tModel tModelKey="uuid:5DD52389-B1A4-4fe7-B131-0F8EF73DD175">
   <name>this is the interface we created</name>
   <description xml:lang="en">interface for Web service 
                 answering num of submissions</description>
   <overviewDoc>
      <description xml:lang="en">The service's WSDL document</description>
      <overviewURL>http://www.codeproject.com/services/interf
                        aces/numOfSubmissions.wsdl</overviewURL>
   </overviewDoc>
   <categoryBag>
      <keyedReference
         tModelKey="uuid:c1acf26d-9672-4404-9d70-39b756e62ab4"
         keyName="Specification for a web service described in WSDL"
         keyValue="wsdlSpec"/>
      <keyedReference
         tModelKey="uuid:c0b9fe13-179f-413d-8a5b-5004db8e5bb2"
         keyName="On-Line Information Services"
         keyValue="514191"/>
      <keyedReference
         keyName="input"
         keyValue="xsd:string"/>
      <keyedReference
         keyName="output"
         keyValue="xsd:integer"/>
   </categoryBag>
</tModel>

Let us say this enhancement is a big success: the world loves this new feature, lots of developers start to use our Web service and this further brings lots of money into our company. Therefore, the company's management team decides that from now on, every new interface that we register with UDDI should have this new enhancement. Now, problems start to show up: different developers in our company start to use different names for "input". One developer names it "input", the other one might call it "myInput", and yet the third one uses "input-0" to represent the input in his interface definition. Certainly the same thing can happen to the output part too.

Now, not only is our own development team getting confused, the outside world is getting frustrated: there is no uniform naming scheme here, so there is no way we can search for "input" or "output" now, because it can be any name they use.

How to solve this problem? By now, probably you know the answer already: use a tModel! List-5 shows the input_tModel that should be registeres with UDDI first:

----------------------------------------------------------
        List-5. tModel is used as a namespace
----------------------------------------------------------

<tModel tModelKey="uuid:E27972D8-717F-4516-A82D-B688DC70170C">
   <name>input_tModel</name>
   <description xml:lang="en">namespace of input_tModel</description>
   <overviewDoc>
      <description xml:lang="en">whatever description you want</description>
      <overviewURL>http://www.ourCompany.com/internalDocuments/
                                inputDetails.html</overviewURL>
   </overviewDoc>
</tModel>

After we create this input_tModel and register it with UDDI (also we should do the same for the output_tModel), we do not need to worry about the different naming schemes: you can use whatever name you want, as long as you reference the input_tModel key when you add your input description into the interface. List-6 shows the results.

----------------------------------------------------
        List-6. tModel is used as a namespace
                A more friendly interface
----------------------------------------------------

<tModel tModelKey="uuid:5DD52389-B1A4-4fe7-B131-0F8EF73DD175">
   <name>this is the interface we created</name>
   <description xml:lang="en">interface for Web service 
                    answering num of submissions</description>
   <overviewDoc>
      <description xml:lang="en">The service's WSDL document</description>
      <overviewURL>http://www.codeproject.com/services/
               interfaces/numOfSubmissions.wsdl</overviewURL>
   </overviewDoc>
   <categoryBag>
      <keyedReference
         tModelKey="uuid:c1acf26d-9672-4404-9d70-39b756e62ab4"
         keyName="Specification for a web service described in WSDL"
         keyValue="wsdlSpec"/>
      <keyedReference
         tModelKey="uuid:c0b9fe13-179f-413d-8a5b-5004db8e5bb2"
         keyName="On-Line Information Services"
         keyValue="514191"/>
      <keyedReference
         tModelKey="uuid:E27972D8-717F-4516-A82D-B688DC70170C"
         keyName="whatever-input-name"
         keyValue="xsd:string"/>
      <keyedReference
         tModelKey="uuid:Key_for_output_tModel"
         keyName="whatever-output-name"
         keyValue="xsd:integer"/>
   </categoryBag>
</tModel>

Now, the problem is solved. It is interesting to notice that here, the input_tModel is used like a namespace: a group of developers now have a common and shared concept of input (and same for the output). For the outside world, assume that one developer in some other company knows this enhancement, so he will first search for a tModel using the name "input_tModel". Once he gets the result back, he can retrieve the key for this input_tModel. The next thing he needs to do is to find all the interfaces that use this tModel in their definitions. The same is true for output_tModel. The result? As you expected, he gets all the interfaces that have this enhancement.

Let me also point out that this is not my invention: if you go to IBM's registry test site, and search for tModels using the name "input_TModel", you will find two of these tModels. For your information, here is the key for one of them, UUID:F53717D0-6A52-11D7-BADE-000629DC0A53. I did write some code to search for all the interfaces that have used this tModel, and guess what, I found one!

Summary

The tModel concept is playing an important role in the world of UDDI, yet it can remain confusing and hard to understand. This article presents three main roles that tModels can play. Namely,:

1. tModels can be used to represent interfaces,
2. tModels can be used to represent classification information which can then be added into interface tModels to make search easier, and finally,
3. tModels can be used as namespaces to add more meanings into the UDDI data structure.

This last role is in fact the main enhancement that is suggested by semantic Web service researchers. Hope this will be of some help to your development work and certainly I welcome any suggestions and comments.