Where Is UDDI?


Like any network resource, Web Services would be impossible to find without some type of prior knowledge of either the location or specific functions exposed. XML Web Service directories like UDDI provide the central repository where a deployed service can publish descriptive information about itself. The UDDI standard defines a publishing methodology that allows either a developer or end user to find and use a Web Service. Published services within UDDI are responsible for providing business, service, and binding information that Web Service consumers can search and read. Within the intranet, Windows Server 2003 provides a standard-based UDDI implementation that is available through the URL http://@ servername :/UDDI . This brings up the default screen shown in Figure 4.8.

click to expand
Figure 4.8: The default Windows Server 2003 UDDI screen.

UDDI is part of the .NET Framework s Microsoft.UDDI namespace. Once a Web Service is registered, UDDI clients and applications like InfoPath are then able to dynamically discover and implement these services using the methods exposed through the Web Service namespace. UDDI registries typically have two kinds of clients . The first is the business user that is publishing a service and its usage interface. The other is a client that needs to locate published services and then bind programmatically to the published interfaces and interact with the service.

Publishing a Service Provider

Web Services are attached to a specific provider. Providers are required to fully disclose their contact and business information. This provides a security level to consumers so they can determine specific security requirements or restrictions. The publishing screen is shown in Figure 4.9.

click to expand
Figure 4.9: The UDDI provider registration screen.

A business entity is part of the UDDI structure that manages the overall provider. This is an additional security layer that assigns a specific unique key or a Globally Unique Identifier (GUID) for registration and security.

Publishing the Service

Based on the provider registration, a set of available services can then be registered. Each service registration represents a single XML Web Service published within the UDDI structure. The default screen is shown in Figure 4.10.

click to expand
Figure 4.10: The UDDI service registration screen.

A service definition can include a variety of additional information that is used to fully describe the Web Service purposes. This includes not only the technical definition of ports and proxies but also a human readable definition and description. Once a service is defined, the bindings are then registered. A binding represents each of the exposed Web Service end points of an .asmx file.

Note  

UDDI provides for multi-language capabilities. This includes adding search information in a variety of languages.

Binding information provides the actual location information needed to access and address the Web Service. Shown in Figure 4.11, this information is used by end-user applications like InfoPath to programmatically bind to a specific Web Service instance.

click to expand
Figure 4.11: The UDDI binding screen.

Publishing the Instance Information

Once the bindings are entered, the next registration requirement is the entry of the specific instance information, as shown in Figure 4.12. Instance information is a pointer to the Technical Model (tModel) schema element. This element defines the type information and classification of the service. tModels are used to contain all the relevant technical information, function calls, and interface definitions supported by the Web Service.

click to expand
Figure 4.12: The UDDI instance entry screen.

The connection between the binding and the metadata is defined through the tModel instance. Similar to a dictionary or reference table in a database, the tModel contains the name , description, and a unique identifier. When called, the tModel provides the translation between the representation of the Web Service key and the actual interfaces.

The schema elements of the tModel, as shown in Figure 4.13, contain metadata information used to access specific type information or classification information for a registered Web Service. UDDI is responsible for storing this information and allows applications like InfoPath access to search through a variety of attributes and methods and then bind to the specific interface.

click to expand
Figure 4.13: The UDDI tModel entry screen.



Programming Microsoft Infopath. A Developers Guide
Programming Microsoft Infopath: A Developers Guide
ISBN: 1584504536
EAN: 2147483647
Year: 2006
Pages: 111
Authors: Thom Robbins

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net