![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
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 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 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.
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.
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.
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.
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.
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.
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.
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>
|
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>
|
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>
|
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>
|
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>
|
This section describes the UDDI artifacts that should be published for each WSDL file.
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.
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
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
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.
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:B711A4B7-A183-43C5-9447-58B91258471F
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.
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:55067855-F7BF-4FFF-81E9-CC1BFDCCE90C
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.
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.
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.
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.
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.
This section describes some queries that can be issued against the UDDI model of the sample application.
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.
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.
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.
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.
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.
- 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.
Table of contents
Local resources
Tags
Use the slider bar to see more or fewer tags.
For articles in technology zones (such as Java technology, Linux, Open source, XML), Popular tags shows the top tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), Popular tags shows the top tags for just that product zone.
For articles in technology zones (such as Java technology, Linux, Open source, XML), My tags shows your tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), My tags shows your tags for just that product zone.
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
