UDDI
The Universal Description, Discovery, and Integration (UDDI) specification defines how to register business data as well as to advertise the existence and location of XML Web Services. As a developer and user of Web Services, you will typically interact with UDDI by either registering your Web Service with UDDI or by looking for Web Services that serve particular needs. When using UDDI, you need to have a good understanding of how to discover what you are looking for. This section will cover the basic concepts you need to understand to publish and discover Web Services.
After reading this overview, you may be interested in the detailed usage of the UDDI Web Service. Microsoft provides an SDK for .NET clients to use when accessing UDDI. This and other resources are listed in Appendix A,“Additional Resources.”
tModels
A tModel, or type model, describes an XML Web Service in detail. Typically, this is a WSDL file that may or may not omit the service element. In UDDI, one organization may register a tModel and several may implement it. For example, the insurance industry may define the semantics for processing health insurance claims using Web Services. An organization representing the insurance industry may register that tModel but not provide the implementations. Instead, the member organizations would provide implementations. Businesses and other organizations that want to be able to access those implementations would provide the clients.
All tModels registered in UDDI get an automatically generated globally unique ID (GUID). If you know the ID of the tModel you want to use in your client application, and if one implementation is as good as another, you can write a generic client that connects to any number of endpoints. As long as they support the tModel, you should be able to connect to the endpoint, regardless of what language it is written in or the platform on which it relies.
Registering with UDDI
When registering with a UDDI Registry, you have two choices—use a user interface or the UDDI SOAP interface. Both the IBM and Microsoft registries have a Web-based user interface. Figure 3.1 shows Microsoft's UDDI administrative user interface.
Figure 3.1. Microsoft's UDDI administrative user interface.
You can visit this site at http://uddi.microsoft.com. The user interface walks you through various steps. You can register your business and declare the types of industries you are involved in and where the business or servers are located. When registering a tModel, you can apply the same information to it. For example, you can declare that you have an XML Web Service that is hosted in Redmond, Washington, USA, and London, England that services the lumber industry and has a WSDL definition. UDDI provides quite a set of capabilities. In Chapter 4, you will take a look at some of the UDDI capabilities built into Visual Studio .NET.
One thing you may not realize is that UDDI is itself an XML Web Service with a SOAP binding. This SOAP interface allows you to programmatically access UDDI registries as well. Using these APIs, you can create applications that publish Web Service details without any human intervention.
By listing your XML Web Service with either Microsoft or IBM (at no cost, by the way), you get some nice advertising benefits. For one, potential users can more easily find the XML Web Service. Another benefit is that the two UDDI registries share information. Every night, Microsoft and IBM share the changes that happened during the day to their registries. If you publish your XML Web Service on Microsoft today, it will be listed on IBM by tomorrow.
Figure 3.2 shows the details of the scottseely.com registration. When I published this business in the Microsoft UDDI registry, that night synchronization brought the content over to IBM.
Figure 3.2. scottseely.com registration at http://uddi.microsoft.com.
One final advantage of registering your Web Service is that it gives your customers a way to find the service again if you ever move it to a different server. By updating the location of the server in the UDDI registry, a client can find the endpoint via a simple query.
Query Patterns
The UDDI specification identifies three different ways that users will use the registry to find the services in which they are interested:
These three patterns all work together to help the user find the business or Web Service they are seeking. After discussing the particular pattern, we will look at how the Microsoft UDDI site implements the pattern to help us discover a Web Service. As a goal, let's look for a Web Service that provides a “quote of the day.”
Browse Pattern
Users employ the browse pattern to help find the group that most likely contains the Web Service or business for which they are looking. The data in UDDI can be organized hierarchically, depending on what makes sense for the users. The browse pattern assumes that a user will search for a set of criteria and then sort through those criteria manually. UDDI has a set of find_xxx APIs that allow users to browse through the data. For example, the find_business API will return a list of businesses based on the name of the business. Likewise, the find_service API will return a list services related to a specific business.
When one of these APIs is called and it returns the list, the user then needs to inspect the list and decide which elements hold any interest. At this point, the user drills into the information using the next pattern—drill-down.
Because the browse API does allow for searching, I will go over to http://microsoft.uddi.com and go to the search page. From there, I will search all the tModel names for the text “quote of the day.” The page and the layout of that search is shown in Figure 3.3.
Figure 3.3. Results of searching for “quote of the day.”
Drill-Down Pattern
The get_xxx APIs handle the inspection of listed items generated by the browse pattern. For example, a user can get information about a business of interest by calling get_businessDetail. If the information about the business looks correct, the user may ask the UDDI registry for a list of all the Web Services that business exposes and then dig into a few of those Web Services. That is, the user will drill down until he or she finds something interesting, browse the contents, and then drill-down some more. This pattern continues until the user either finds what he or she is looking for or discovers that the item does not exist in the UDDI store.
After the user has selected a Web Service, he or she may need to make arrangements with the provider of that Web Service to access it. This may mean acquiring a license, signing a contract, or doing nothing. The user will then create a proxy that can access the Web Service, test the application that uses the proxy, and distribute the application. After the application is deployed, the user will need a way to find the endpoint should the owner of the Web Service ever decide to move the servers. To handle the potential movement of the server, the UDDI specification recommends the use of the invocation pattern.
Going back to the search for a quote of the day Web Service, I did find three potential candidates. Now, I need to drill down into the results and see if any of them meet my needs. To go straight to the details of each Web Service, I click the Details link. This brings up the data in Figure 3.4. I can drill down deeper and check out the WSDL from the page as well as any other links the owner of the Web Service has provided.
Figure 3.4. Drilling into the first result of the search.
Invocation Pattern
The invocation pattern spells out how a Web Service client should use UDDI to keep the endpoint up to date. A client application will use data cached from the UDDI registry. When using Visual Studio, the user's application caches this information when creating the initial proxy. The client will then proceed to use that cached information until a Web Service call fails. If the call fails because the client cannot connect to the endpoint, the client goes to the UDDI registry and posts an inquiry to find the endpoint of the Web Service. The client then takes the information regarding the location of the endpoint and tries to make a new call. If the call succeeds, the client saves the new location and uses it until another failure happens. If the call fails again, the client can look for another service implementing the tModel, or it can fail completely and post a notification for a human operator to respond to.
A Visual Basic .NET client application would keep everything up to date by caching the ID for the endpoint. The proxy code would then be modified to handle instances where the service could not even be contacted. In those cases, the client would requery the UDDI registry using the Microsoft UDDI SDK. If the endpoint's URL had changed, the client application would update the endpoint and update the stored URL.