Partager via

Web services are a peach, and then? UDDI!

  • Article

I’ve been blogging quite a bit about the brave new world of data connection libraries and UDC files. A data connection library is the recommended way to expose data connections for use in enterprise InfoPath forms. Users can easily select an appropriate connection by name and description without needing to know the connection details – or even the type of connection. Web services, database queries, SharePoint list queries, ASPX pages that return an XML stream – they all look equally friendly.

Data connection libraries come as a standard library type on the 2007 Microsoft Office Server. But the unfortunate fact is that not everybody has Office Server installed and configured yet. For those of you who need to provide simple discovery of Web service connections in the interim, I’m going to dust off an older, poorly understood, and yet still perfectly functional technology called UDDI. UDDI stands for Universal Description, Discovery and Integration, and it’s a standard way of exposing web service interfaces on a network. For more information on the UDDI standard, check out http://www.UDDI.org.

InfoPath allows you to search a UDDI server when setting up a Web service connection. In the pane where you are asked to specify a WSDL file, clicking “search UDDI” brings up the UDDI discovery dialog:

This UDDI discovery feature was not much used in InfoPath 2003 for several reasons.

First of all, the default UDDI server listed was a public internet UDDI registry that was co-hosted by Microsoft and IBM. This joint venture was envisioned as a central repository that would become the one place to go on the Internet to discover useful web services. The joint project did not turn out to be successful, so it was terminated earlier this year (see http://www.webservicessummit.com/News/UDDI2006.htm ). However, this does not mean that UDDI is not a viable technology, just that the central Internet registry is not generally useful. UDDI in a more scoped environment such as a corporate intranet is still useful.

Secondly, UDDI does not allow for filtering results based on the style and encoding of the Web service. Many of the Web services exposed through the Microsoft/IBM registry used the RPC style. InfoPath supports only the document style and the literal encoding, and UDDI did not allow us to filter the displayed list to only those services which InfoPath could support. Exposing UDDI on your intranet allows you to limit the exposed web services to document literal web services designed for use in InfoPath.

Let me show you how easy it is to set up a UDDI server.

First off, you need to have a Windows 2003 server set up as an application (web) server. Go into the add/remove programs control panel and choose “add/remove windows components”. In the list, select the check box for UDDI services and follow the wizard to install this component.

I’m going to assume that you already have one or more Web services deployed. These can be on any server (not just the server on which you’re configuring UDDI). The important thing to have is a URL to the WSDL for each service you plan to register.

For example, here’s a description of a web service on my personal server. It exposes a number of functions for doing calculations based on my daughter’s current age. Because this is a standard asp.net web service, I can get the WSDL for the service by appending ?WSDL to the end of the URL.

Once UDDI is installed, go to the UDDI home page, and click “Publish” to start editing the registration entries for the server.

The first thing you want to do is to create a tModel for each service you want to expose. A tModel is a data structure that describes how a service description is exposed. For our purposes, a tModel is simply a pointer to the WSDL file for the service. UDDI Services in Windows Server 2003 makes it easy to create the model, enter the WSDL URL and some descriptive text that will show up in the UI.

Once you have tModels for your services, you will want to create one or more providers. There’s nothing magic about providers – they are simply names used to provide logical groupings of services. I use a single provider representing my personal website, and all services are exposed under that provider.

Once you’ve defined the provider, you’ll add one or more services to the provider. For each service, you’ll specify a name, a description, and one or more bindings. The binding is simply an access point for the service. In this case, we’re using the URL to the WSDL file for the service. To specify this, we specify a binding instance, and the binding instance is simply a reference to the tModel we already created.

Note that the category tab for the service allows you to optionally associate categories with services to provide an additional level of abstraction. Categories are optional and probably unnecessary unless you have a great many services in your registry.

The final piece of the puzzle is to tie this all back to InfoPath. Empirically, Windows Server 2003 UDDI Services appears to expose UDDI through a web service interface at http://YourServname/YourPublicUDDIPath/inquire.asmx. You’ll want to type this full URL into the UDDI server field. Choose to search either providers or services, and type a search term in the Search For field. I usually type the wildcard operator “%” to search all services. This brings up a list of available services in the Search Results list box. Selecting a service in this box and clicking OK will populate the data connection wizard with the WSDL location for the service, and you’re off and running.

Nick Dallett
Program Manager

Comments

  • Anonymous
    December 19, 2006
    Skills measured by exam 70-529 Creating and Accessing XML Web Services Create and configure an XML Web