Use UDDI (Microsoft) at runtime)

Use UDDI at runtime
Karsten Januszewski
Microsoft Corporation
December 2001
Abstract: This article provides an overview of the use of UDDI during runtime and discusses the use of UDDI (public registry and UDDI service in Microsoft Windows.. NET Server) how to use as the Web service infrastructure to support client applications.
Directory overview
Basic structure example solution for running UDDI Web service: C #. NET. asmx Web service: C # Windows Forms. NET client Other solution summary
UDDI (general description, discovery, and integration) is generally referred to as the Yellow Pages of Web services ". Although yellow pages are useful for understanding, they do not fully reflect how UDDI is incorporated into a Web service-based software architecture. The Yellow Pages analogy only involves the design usage of UDDI, that is, searching based on keywords, categories, or interfaces to find and use the functions of Web services. From the design point of view, the Yellow Pages analogy is very accurate: just as the Yellow Pages classify enterprises and their phone numbers into directories, UDDI classifies providers and their Web services into directories. Developers can search for the WSDL file and entry point in UDDI and then integrate these Web services into client applications.
However, UDDI not only provides design support. The Yellow Pages analogy does not mention how UDDI supports runtime. After the discovery process is completed, UDDI plays a very important role. The ability to query UDDI in programming at run time enables UDDI to be used as the basis for building a reliable and robust Web service application. Basic structure of UDDI runtime
After you integrate Web services into client applications, you need to consider possible problems. One of the key problems is that you cannot predict or detect faults of Web service providers, or recover from the fault. What measures can the client application take if the Web service fails? How can an application be properly and dynamically recovered from a failed Web service call?
Similarly, from the perspective of Web service providers, how does the Web service owner dynamically update the changes? We need to consider moving Web services to new servers. How can I effectively notify the Web service client of this change? How does the owner send this message at runtime without interrupting all Web service clients?