9.6 Consuming an Internal Web Service

---

When designing the client, our garment Web service would be 'discovered' by developers wishing to utilize it. The WSDL file would be downloaded and a proxy class generated using Add Web Reference in Visual Studio.NET or a command-line tool called WSDL.exe, which ships as part of the Microsoft .NET Framework SDK. In practice, most developers would probably be using Visual Studio.

The utilization application in our example will be a Windows Form application (Win Form standalone executable) used by users to query the sales figures.

The UDDI .NET SDK classes need to be added to the project and then a configuration file built to store the access point for the UDDI server that located our garment sales Web service since UDDI also runs as a Web service. The bindingKey of the Web service is also stored in the same configuration file, which, as expected, will exist as an XML file. The configuration file will be stored in the /bin directory once the application is compiled or built and will then be named after the executable file.

The client application is now built with all of the usual buttons and text boxes, which will enable the sales search parameters to be entered into the form as users search for sales across a certain time period.

Application code is added as you would expect, but we add an additional function to query the UDDI server to find the Web service access point. The actual accessPoint value is stored as a variable, so if the application is restarted, UDDI will be requeried for the accessPoint value, enabling any changes to the Web service to be automatically refreshed.

If there is a problem with accessing the service, the application will automatically try to check out the status of the Web service.

If the accessPoint is requeried and the same value is returned, it is a good indicator that the service provider has not updated the service and there is probably a problem with the service at that moment in time. At that point there is not a lot an application can do other than let the service provider know its Web service is broken!

If a different value for accessPoint is returned from UDDI, the Web service can be invoked again since it has probably been updated by the service provider.

---