A new approach to UDDI and WSDL, Part 3: An example of the new OASIS UDDI WSDL Technical Note in action

Applying the new Technical Note

John Colgrave, Senior Software Engineer, IBM United Kingdom Limited

John Colgrave is the architect of the IBM WebSphere UDDI Registry and a member of the OASIS UDDI Specifications Technical Committee. He is one of the authors of the new OASIS UDDI Technical Note on using UDDI and WSDL. You can contact John at colgrave at uk.ibm.com.

Summary: This is the third article in a series of articles concerning a new approach to using WSDL and UDDI, described in a new OASIS UDDI Technical Note. This article presents an example of applying the approach defined in the new Technical Note.

View more content in this series

Tag this!

Date: 28 Oct 2003
Level: Advanced
Activity: 858 views

The first article in this series (see Resources) introduced and described the new approach to constructing a UDDI model of a WSDL description. The second article described the types of UDDI query that are enabled by this new approach, with examples of several queries given in the form of UDDI V2 API requests. This third article will present a more complex example than the one in the Technical Note, including screen shots showing how to publish the UDDI entities and how to construct the types of query described in the Technical Note and in Part 2 of this series. Subsequent articles will describe how to write Java applications that can publish these models to UDDI and issue the queries, using UDDI4J.

The UDDI Registry used

The UDDI Registry used in this example is an instance of the UDDI implementation that is shipped with IBM WebSphere Application Server Network Deployment, 5.0.2. I have added the tModels required by the new Technical Note to the registry and also the tModel required by WS-I. I have also added a custom taxonomy for the WSDL Entity Type Category System so that the WSDL entity type can be chosen from the category tree view.

The example

The example I have chosen is the Supply Chain Management Sample Application defined by WS-I. The architecture document describing this application includes details on how to publish information about the application to UDDI, using the old UDDI/WSDL Best Practice approach, so this is a particularly good example as the differences between the approaches should be clear.

Overview of sample WSDL

There are five WSDL files published as part of the WS-I sample application that are relevant, each of which contains at least one portType and at least one binding. There are no WSDL service or port descriptions published as the current WS-I Basic Profile uses the existing Version 1 Best Practice approach, and that approach does not consider the WSDL service.

It is not strictly necessary to have a WSDL description of a service and a port to use the new Technical Note approach either, but I have invented five businesses which each implement one of the defined bindings, and I have invented a simple WSDL service description for each one and used these descriptions to produce the businessService and bindingTemplate definitions, as described in the Technical Note.

Each file is described in more detail in the following sections.

Configurator.wsdl

The targetNamespace for this file is http://www.ws-i.org/SampleApplications/SupplyChainManagement/2002-08/Configurator.wsdl and one portType is defined, ConfiguratorPortType, and one binding, ConfiguratorBinding.

LoggingFacility.wsdl

The targetNamespace for this file is http://www.ws-i.org/SampleApplications/SupplyChainManagement/2002-08/LoggingFacility.wsdl and one portType is defined, LoggingFacilityLogPortType, and one binding, LoggingFaclitySoapBinding.

Manufacturer.wsdl

The targetNamespace for this file is http://www.ws-i.org/SampleApplications/SupplyChainManagement/2002-10/Manufacturer.wsdl and in this case two portTypes are defined, ManufacturerPortType and WarehouseCallbackPortType, and two bindings, ManufacturerSoapBinding and WarehouseCallbackSoapBinding.

Only one portType, ManufacturerPortType, and one binding, ManufacturerSoapBinding, are intended to be published to UDDI.

Retailer.wsdl

The targetNamespace for this file is http://www.ws-i.org/SampleApplications/SupplyChainManagement/2002-08/Retailer.wsdl and one portType is defined, RetailerPortType, and one binding, RetailerSoapBinding.

Warehouse.wsdl

The targetNamespace for this file is http://www.ws-i.org/SampleApplications/SupplyChainManagement/2002-08/Warehouse.wsdl and one portType is defined, WarehouseShipmentsPortType, and one binding, WarehouseSoapBinding.

ConfiguratorA.wsdl

This is the first of the invented WSDL files. ConfiguratorA is a fictitious implementer of the Configurator interface. Its WSDL service description is shown in Listing 1.

Listing 1. WSDL description of ConfiguratorA service.

<definitions
   xmlns="http://schemas.xmlsoap.org/wsdl/"
   xmlns:Configurator_binding=
    "http://www.ws-i.org/SampleApplications/SupplyChainManagement/2002-08/Configurator.wsdl"
   xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
   targetNamespace="urn:x-configuratora.com:configurator_service">
<import
   namespace=
   "http://www.ws-i.org/SampleApplications/SupplyChainManagement/2002-08/Configurator.wsdl"
   location=
   "http://www.ws-i.org/SampleApplications/SupplyChainManagement/2002-08/Configurator.wsdl"/>
      <service name="Configurator_Service">
         <port name="Configurator_Port" binding="Configurator_binding:ConfiguratorBinding">
            <soap:address location="http://configuratora.com/Configurator/"/>
         </port>
      </service>
</definitions>

LoggingFacilityA.wsdl

This is the second of the invented WSDL files. LoggingFacilityA is a fictitious implementer of the LoggingFacility interface. Its WSDL service description is shown in Listing 2.

Listing 2. WSDL description of LoggingFacilityA service.

<definitions
   xmlns="http://schemas.xmlsoap.org/wsdl/"
   xmlns:LoggingFacility_binding=
     "http://www.ws-i.org/SampleApplications/SupplyChainManagement/2002-08/LoggingFacility.wsdl"
   xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
   targetNamespace="urn:x-loggingfacilitya.com:loggingfacility_service">
<import
   namespace=
   "http://www.ws-i.org/SampleApplications/SupplyChainManagement/2002-08/LoggingFacility.wsdl"
   location=
   "http://www.ws-i.org/SampleApplications/SupplyChainManagement/2002-08/LoggingFacility.wsdl"/>
      <service name="LoggingFacility_Service">
         <port name=
         "LoggingFacility_Port" binding="LoggingFacility_binding:LoggingFacilitySoapBinding">
            <soap:address location="http://loggingfacilitya.com/LoggingFacility/"/>
         </port>
      </service>
</definitions>

ManufacturerA.wsdl

This is the third of the invented WSDL files. ManufacturerA is a fictitious implementer of the Manufacturer interface. Its WSDL service description is shown in Listing 3.

Listing 3. WSDL description of ManufacturerA service.

<definitions
   xmlns="http://schemas.xmlsoap.org/wsdl/"
   xmlns:Manufacturer_binding=
    "http://www.ws-i.org/SampleApplications/SupplyChainManagement/2002-10/Manufacturer.wsdl"
   xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
   targetNamespace="urn:x-manufacturera.com:manufacturer_service">
<import
   namespace=
   "http://www.ws-i.org/SampleApplications/SupplyChainManagement/2002-10/Manufacturer.wsdl"
   location=
   "http://www.ws-i.org/SampleApplications/SupplyChainManagement/2002-08/Manufacturer.wsdl"/>
      <service name="Manufacturer_Service">
         <port name="Manufacturer_Port" binding="Manufacturer_binding:ManufacturerSoapBinding">
            <soap:address location="http://manufacturera.com/Manufacturer/"/>
         </port>
      </service>
</definitions>

RetailerA.wsdl

This is the fourth of the invented WSDL files. RetailerA is a fictitious implementer of the Retailer interface. Its WSDL service description is shown in Listing 4.

Listing 4. WSDL description of RetailerA service.

<definitions
   xmlns="http://schemas.xmlsoap.org/wsdl/"
   xmlns:Retailer_binding=
    "http://www.ws-i.org/SampleApplications/SupplyChainManagement/2002-08/Retailer.wsdl"
   xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
   targetNamespace="urn:x-retailera.com:retailer_service">
<import
   namespace=
   "http://www.ws-i.org/SampleApplications/SupplyChainManagement/2002-08/Retailer.wsdl"
   location=
   "http://www.ws-i.org/SampleApplications/SupplyChainManagement/2002-08/Retailer.wsdl"/>
      <service name="Retailer_Service">
         <port name="Retailer_Port" binding="Retailer_binding:RetailerSoapBinding">
            <soap:address location="http://retailera.com/Retailer/"/>
         </port>
      </service>
</definitions>

WarehouseA.wsdl

This is the fifth of the invented WSDL files. WarehouseA is a fictitious implementer of the Warehouse interface. Its WSDL service description is shown in Listing 5.

Listing 5. WSDL description of WarehouseA service.

<definitions
   xmlns="http://schemas.xmlsoap.org/wsdl/"
   xmlns:Warehouse_binding=
    "http://www.ws-i.org/SampleApplications/SupplyChainManagement/2002-08/Warehouse.wsdl"
   xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
   targetNamespace="urn:x-warehousea.com:warehouse_service">
<import
   namespace=
   "http://www.ws-i.org/SampleApplications/SupplyChainManagement/2002-08/Warehouse.wsdl"
   location=
   "http://www.ws-i.org/SampleApplications/SupplyChainManagement/2002-08/Warehouse.wsdl"/>
      <service name="Warehouse_Service">
         <port name="Warehouse_Port" binding="Warehouse_binding:WarehouseSoapBinding">
            <soap:address location="http://warehousea.com/Warehouse/"/>
         </port>
      </service>
</definitions>

Publishing the UDDI Model

This section describes the UDDI artifacts that should be published for each WSDL file.

Configurator.wsdl

A portType tModel must be published for the ConfiguratorPortType portType. Looking at section 2.4.1 of the Technical Note we can see that the tModel name must be ConfiguratorPortType, the target namespace must be defined as a keyedReference in the categoryBag and the location of the WSDL document must be defined as the overviewURL value of the tModel.

Figure 1 shows the screen at the point of publishing the tModel. You can see in the category tree on the left the WSDL Entity Types taxonomy with the four defined values.

Figure 1. Publishing portType tModel for ConfiguratorPortType.

When I published this tModel I got a key of uuid:209C7220-0D2D-4DE7-B576-202590207650

A binding tModel must be published for the ConfiguratorBinding binding. The name of the binding tModel must be ConfiguratorBinding. The overviewURL of the binding tModel must contain the URL of the WSDL file, as with the portType tModel. The binding tModel has more categorization information than a portType tModel. Following section 2.4.2 in the Technical Note, the binding tModel has six keyedReferences, including those for the protocol (SOAP in this case) and the transport (HTTP in this case). I have added a seventh keyedReference to declare conformance to the WS-I Basic Profile 1.0. In the WSDL, conformance was only claimed for the binding so I have only claimed it for the binding tModel. If conformance was also claimed for the portType then I would have added a keyedReference to the portType tModel. Figure 2 shows the screen immediately after publishing the binding tModel, and the seven keyedReferences can be seen. Note that the key of the portType tModel is used as the keyValue of the keyedReference for the portTypeReference Category System.

Figure 2. Published binding tModel for ConfiguratorBinding.

When I published this tModel I got a key of uuid:21538B21-04C9-4932-A44B-776B2F774B40.

LoggingFacility.wsdl

A portType tModel must be published for the LoggingFacilityLogPortType portType.

The process is the same as for the ConfiguratorPortType tModel, but the tModel name, the namespace and the location of the WSDL document must be changed as appropriate.

When I published this tModel I got a key of uuid:305ABA30-CD18-483F-A47A-6A796E6A7A0A

A binding tModel must be published for the LoggingFacilitySoapBinding binding.

The process is the same as for the ConfiguratorBinding tModel, but the tModel name, the namespace, the location of the WSDL document and the portType tModel key used in the portTypeReference keyedReference must be changed as appropriate.

When I published this tModel I got a key of uuid:5FAA465F-35A0-401C-A653-CE161ECE5389

Manufacturer.wsdl

A portType tModel must be published for the ManufacturerLogPortType portType.

The process is the same as for the ConfiguratorPortType tModel, but the tModel name, the namespace and the location of the WSDL document must be changed as appropriate.

When I published this tModel I got a key of uuid:E884BAE8-7608-48AF-A43A-DCB273DC3A83

A binding tModel must be published for the ManufacturerSoapBinding binding.

The process is the same as for the ConfiguratorBinding tModel, but the tModel name, the namespace, the location of the WSDL document and the portType tModel key used in the portTypeReference keyedReference must be changed as appropriate.

When I published this tModel I got a key of uuid:94549194-A402-42FE-9FD5-E0725CE0D532

Retailer.wsdl

A portType tModel must be published for the RetailerPortType portType.

The process is the same as for the ConfiguratorPortType tModel, but the tModel name, the namespace and the location of the WSDL document must be changed as appropriate.

When I published this tModel I got a key of uuid:6770B367-4D69-490B-A4BF-BCB226BCBF63

A binding tModel must be published for the RetailerSoapBinding binding.

When I published this tModel I got a key of uuid:B711A4B7-A183-43C5-9447-58B91258471F

Warehouse.wsdl

A portType tModel must be published for the WarehouseShipmentsPortType portType.

The process is the same as for the ConfiguratorPortType tModel, but the tModel name, the namespace and the location of the WSDL document must be changed as appropriate.

When I published this tModel I got a key of uuid:385CC638-D3E4-443E-8424-2E36DE2E240B

A binding tModel must be published for the WarehouseSoapBinding binding.

When I published this tModel I got a key of uuid:55067855-F7BF-4FFF-81E9-CC1BFDCCE90C

ConfiguratorA.wsdl

A businessService must be published for the Configurator_Service service containing a bindingTemplate for the Configurator_Port port. I published a businessEntity called ConfiguratorA to contain the businessService.

Figure 3 shows the entities I own after publishing the ConfiguratorA business and the other invented businesses.

Figure 3. Invented businessEntities.

The current IBM WebSphere UDDI Registry user console combines the information about a service and its bindingTemplates into a single screen so the following sequence of figures describes how to configure both the service and the bindingTemplate.

To add a businessService and its bindingTemplate to the ConfiguratorA businessEntity, click on the "Add service" icon under Services for ConfiguratorA. This will display the "Publish Service" form.

Enter a name of ConfiguratorA's Configurator Service and click on Add.

In the Access Points section enter an Address of http://configuratora.com/Configurator/ which is the value of the location attribute of the soap:address element of the port. Click Add.

Figure 4 shows the form as it should be at this point.

Figure 4. Name and Access Point added to ConfiguratorA Service.

The next section of the form is the Locator section which is where the keyedReferences are added to the categoryBag of the service. Looking at section 2.4.3 of the Technical Note, three keyedReferences are necessary. To enter the keyedReference for the WSDL Entity Type Category System you can either click on "Show category tree" and choose the value from the category tree view, or you can choose the Category System from the "New category:" drop-down menu and enter the value manually. Whichever method you choose, click Add to add the keyedReference. For the other two keyedReferences, choose the appropriate Category System from the drop-down menu and enter the appropriate value, then click Add.

Figure 5 shows how the Locator section should now appear.

Figure 5. Locators added to ConfiguratorA Service.

The final section of the form is the "Technical Models" section which is where the tModels are added to the bindingTemplate of the businessService. The way this is accomplished in the IBM WebSphere UDDI Registry user console is by searching for tModels and selecting the ones to be added. To begin this process, click on the Add... icon in the Actions column. This will display the "Find Technical Models" form as shown in Figure 6.

Figure 6. Find Technical Models form.

If you have started with a clean registry, the tModels for both the binding and the portType can be found by searching for tModels with a name beginning with Config. Enter Config in the field labeled "Starting with:" and click on "Find Technical Models". You should see a Results form with two tModels displayed, ConfiguratorBinding and ConfiguratorPortType. Select each of these and click Update. You should now be back at the Publish Service form and the Technical Models section should look like Figure 7.

Figure 7. Technical Models section of Publish Service form.

Click on "Publish Service" to publish the businessService and its bindingTemplate. The current IBM WebSphere UDDI Registry user console does not allow the instanceParms to be entered so it is not possible to add the port name, as the Technical Note requires, using the user console.

LoggingFacilityA.wsdl

A businessService must be published for the LoggingFacility_Service service containing a bindingTemplate for the LoggingFacility_Port port. I published a businessEntity called LoggingFacilityA to contain the businessService.

I added a service named LoggingFacilityA's LoggingFacility Service following the same steps as described above for ConfiguratorA's service, but with appropriate names, locations, tModels etc.

ManufacturerA.wsdl

A businessService must be published for the Manufacturer_Service service containing a bindingTemplate for the Manufacturer_Port port. I published a businessEntity called ManufacturerA to contain the businessService.

I added a service named ManufacturerA's Manufacturer Service following the same steps as described above for ConfiguratorA's service, but with appropriate names, locations, tModels etc.

RetailerA.wsdl

A businessService must be published for the Retailer_Service service containing a bindingTemplate for the Retailer_Port port. I published a businessEntity called RetailerA to contain the businessService.

I added a service named RetailerA's Retailer Service following the same steps as described above for ConfiguratorA's service, but with appropriate names, locations, tModels etc.

WarehouseA.wsdl

A businessService must be published for the Warehouse_Service service containing a bindingTemplate for the Warehouse_Port port. I published a businessEntity called WarehouseA to contain the businessService.

I added a service named WarehouseA's Warehouse Service following the same steps as described above for ConfiguratorA's service, but with appropriate names, locations, tModels etc.

Querying the UDDI Model

This section describes some queries that can be issued against the UDDI model of the sample application.

Querying portType tModels

To search for portType tModels, click on "Find technical models" in the "Advanced Find" section of the home page of the IBM WebSphere UDDI Registry user console. To restrict the search to portType tModels, enter a locator for the WSDL Entity Types Category System with a value of portType. This can be done either through the category tree or by choosing the Category System from the drop-down menu and entering the value manually. If all portType tModels are desired, that is all that is necessary. Figure 8 shows the "Find Technical Models" form with just the WSDL Entity Types locator specified.

Figure 8. Find Technical Models form to search for all portType tModels.

Figure 9 shows the results when I executed this query against my registry containing just the sample application artifacts.

Figure 9. Results of Find Technical Models.

To search for a tModel for a particular portType, the name of the portType is specified as the tModel name and the namespace is added as a locator using the XML Namespace Category System. Figure 10 shows a query for the ConfiguratorPortType portType tModel.

Figure 10. Search for a specific portType tModel.

As I used the full name for the portType I chose the "exact match" and "case sensitive" options.

This query returns just the ConfiguratorPortType tModel.

Querying binding tModels

To show both how to query using a mixture of WSDL and other information, and how to query for bindings for a particular portType, we will search for binding tModels that declare conformance to the WS-I Basic Profile 1.0 and that represent bindings of the ManufacturerPortType portType. Figure 11 shows the "Find Technical Models" form with the appropriate Locators added.

Figure 11. Search for a WS-I conformant binding for ManufacturerPortType.

This query returns just the ManufacturerSoapBinding tModel. The search could be restricted to SOAP or SOAP and HTTP by adding further locators using the protocol and transport category systems.

Querying businessServices

Searching for a businessService that corresponds to a WSDL service is done using several Locators on the "Find services" form. Figure 12 shows an example of a query for the businessService corresponding to the Warehouse service offered by the fictitious WarehouseA.

Figure 12. Search for a businessService by name.

This query returns just WarehouseA's Warehouse Service.

To search for implementations of a portType and/or a particular binding for that portType, we have to add other tModels. These tModels are added by clicking on the "Add..." icon in the "Technical Models" section of the "Find Services" form. I searched for the RetailerPortType portType by name but any of the options are available. Figure 13 shows a query for implementations of the RetailerPortType portType.

Figure 13. Search for implementations of RetailerPortType.

This query returns just RetailerA's Retailer Service in this example. By clicking on this service the details of the service are displayed and the appropriate accessPoint etc can be seen.

These two approaches can be combined.

Querying bindingTemplates

The IBM WebSphere UDDI Registry user console does not currently support querying bindingTemplates explicitly so once a businessService has been chosen the appropriate information must be read from the display of the businessService.

Conclusion

This article has applied the approach defined in the Technical Note to a significant sample WSDL description, namely the WS-I Supply Chain Management sample application. The details of each UDDI artifact published have been given and some sample queries shown.

The next article in this series will cover how to write code to publish the different UDDI artifacts for a WSDL description.

Resources

Read the other parts of this series:
- "A new approach to UDDI and WSDL, Part 1" (developerWorks, August 2003) describes the new Technical Note on using WSDL and UDDI together.
- "A new approach to UDDI and WSDL, Part 2" (developerWorks, September 2003) describes the queries that are supported by the approach defined in the new Technical Note.
- "A new approach to UDDI and WSDL, Part 4" (developerWorks, October 2003) describes how to publish and query the UDDI model for the WS-I Sample Application, following the approach defined in the new Technical Note.
- "A new approach to UDDI and WSDL, Part 5" (developerWorks, October 2004) describes how to apply the approach defined in the new OASIS UDDI Technical Note to query from a Java application.
The WS-I Sample Application "Supply Chain Management Sample Application Architecture" is published by the Web Services-Interoperability Organization.
The OASIS UDDI Specifications Technical Committee is now responsible for UDDI standards.
This article is based on the Technical Note "Using WSDL in a UDDI Registry, Version 2.0" which has recently been published as an official Technical Note by the OASIS UDDI Specifications Technical Committee.
The previous Best Practice "Using WSDL in a UDDI Registry, Version 1.08" has been updated by the OASIS UDDI Specifications Technical Committee since the previous developerWorks articles were written.
Access Web services knowledge, tools, and skills with Speed-start Web services, which offers the latest Java-based software development tools and middleware from IBM (trial editions), plus online tutorials and articles, and an online technical forum.
Browse for books on these and other technical topics.
Want more? The developerWorks SOA and Web services zone hosts hundreds of informative articles and introductory, intermediate, and advanced tutorials on how to develop Web services applications.

About the author

Comments (Undergoing maintenance)

Trademarks | My developerWorks terms and conditions

Close [x]

Help: Update or add to My dW interests

What's this?

This little timesaver lets you update your My developerWorks profile with just one click! The general subject of this content (AIX and UNIX, Information Management, Lotus, Rational, Tivoli, WebSphere, Java, Linux, Open source, SOA and Web services, Web development, or XML) will be added to the interests section of your profile, if it's not there already. You only need to be logged in to My developerWorks.

And what's the point of adding your interests to your profile? That's how you find other users with the same interests as yours, and see what they're reading and contributing to the community. Your interests also help us recommend relevant developerWorks content to you.

View your My developerWorks profile

Return from help

Close [x]

Help: Remove from My dW interests

What's this?

Removing this interest does not alter your profile, but rather removes this piece of content from a list of all content for which you've indicated interest. In a future enhancement to My developerWorks, you'll be able to see a record of that content.

View your My developerWorks profile

Return from help

static.content.url=http://www.ibm.com/developerworks/js/artrating/

SITE_ID=1

Zone=SOA and Web services

ArticleID=11854

ArticleTitle=A new approach to UDDI and WSDL, Part 3: An example of the new OASIS UDDI WSDL Technical Note in action

publish-date=10282003

author1-email=

author1-email-cc=