9.5 UDDI XML Schema

 < Day Day Up > 



The UDDI specifications contain both an XML schema for use by SOAP messages and a description of the UDDI API.

Within the XML schema there are four core types of information that provide everything a developer would need to know to utilize a partner's Web service.

  1. Business information

  2. Service information

  3. Binding information

  4. Specification information

9.5.1 Business Information Element

The chances are that organizations wishing to utilize your Web service will have some information about your company, such as the name, or a business identifier, such as a Dun and Bradstreet or company registration number. The businessEntity structure uses XML elements to store information about a business. The structure of the businessEntity element is such that yellow-pages-type searches can be conducted against a business to find out where the business is located or which specific industrial categories it serves.

9.5.2 Services Information Elements

The green-pages data, which has technical and business descriptions of the services provided, is stored in substructures of the businessEntity element.

These structures are the businessService and bindingTemplate. The businessService element stores a group of Web services that relate to a business process or set of services, as well as other technical information to describe the technical side of the services.

9.5.3 Binding and Specification Information

Knowing that a Web service sits on your business partner's Web site at a specific URL is only half the battle. There is a host of other information about the service, such as the security model used, the protocols used, and the format of the document, that needs to be known before you can start to connect to the service and exchange data. This information is called the Web service technical fingerprint and is stored in the bindingTemplate information element.

UDDI and Runtime Support

Runtime support is probably one of the most important issues to developers building UDDI-based solutions. The use of the business registry is fine for design-time activities, but developers building Web services need to be able to query UDDI programmatically.

Building reliable applications using Web services introduces a host of issues concerned with service-level agreements and intercompany support for applications. If a Web service should fail, how is the developer expected to manage the failure and allow alternate Web services to be used or to close down the application gracefully? On the other hand, the Web service provider needs to manage and maintain its own servers and needs to be able to inform service consumers of changes dynamically so that applications are not broken.

UDDI does have a role to play in providing a service-level guarantee to service providers and consumers. It has a calling convention, which caches binding information about the implementation that can be refreshed if a failure occurs.

The typical run-time process is as follows. The Web service is searched for within UDDI. Once discovered, the WSDL file and any implementation details are utilized from the UDDI bindingTemplate, which contains such things as the access point and configuration information. The client application needs to retrieve all of the relevant information from UDDI; it does this by caching the bindingKey of the Web service. The remote Web service is then invoked using the cached data from the UDDI Web registry.

If there is a problem running the Web service, two APIs-the bindingKey value and get_bindingTemplate -are called to refresh the binding information. The new and old information are then compared, and, if there is a difference, the failed call is retried so that the cached data can be refreshed for later use. If the binding information is the same, the Web service provider hasn't made any changes, and this will be detected by the application.

Almost inevitably the Web service will be updated, so if a redirection to a new Web service location needs to be made, the only change that needs to be made is the access point in the UDDI registry. All subsequent Web service access will then be to the new location-be it temporary or permanent.

Using UDDI Internally

The following example will give you an idea of how UDDI and Web services can be used in an organization. The example will focus on access to information regarding daily sales of garments from a private Web service deployed by the sales department of a clothing company.

The garment Web service is simple since it only has a single method, called GetGarmentSales , that allows access to a SQL Server database fed from a point-of-sale system from the store's network. This is updated using a BizTalk Server-based message queue infrastructure and is constantly refreshed with new incoming transactions. The client that wishes to access this sales information will cache the access point and bindingKey information and have some built-in robustness by refreshing its UDDI registry cache if there is a failure.

The Web service is built inside Visual Studio.NET using an appropriate .NET language, such as Visual Basic or C#. Since the Web service is fairly simple, it has a single method, GetGarmentSales , that retrieves garment sales based on two times given as input, so that garment sales can be seen from, for example, 10:00 A.M. to 3:00 P.M. The Web service code is created and then saved as an .asmx page called GetGarmentSales.asmx.

The page needs to be stored in a virtual directory on a Web site. To deploy the Web service it needs to be registered into an internal or private UDDI Server. Microsoft provides a local UDDI server in Microsoft Windows .NET Server, or developers can install a local UDDI server by using the Microsoft UDDI SDK.

The Web service can be registered via the Web user interface or directly using the UDDI SDK, which is probably the preferred method to speed up the process. The WSDL file needs to be registered as a tModel, which will then represent the Web service interfaces as XML and abstract any associated metadata. The access point for the Web service is then registered as a bindingTemplate, which is an XML-based structure used to show how a Web service has been implemented. The key values generated by UDDI are unique for our Web service entities and provide a way of identifying our service uniquely throughout UDDI (see Figure 9.5).

click to expand
Figure 9.5: GetGarmentSales Web service.

The accessPoint and bindingKey are two important bits of information used by the client to identify the correct Web service and then use the accessPoint to find the URL and location of the service. If at any time the client needs access to the WSDL, the tModelKey is used to query UDDI to return it.



 < Day Day Up > 



Microsoft  .NET. Jumpstart for Systems Administrators and Developers
Microsoft .NET: Jumpstart for Systems Administrators and Developers (Communications (Digital Press))
ISBN: 1555582850
EAN: 2147483647
Year: 2003
Pages: 136
Authors: Nigel Stanley

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