لطفا منتظر باشید ...
Directories
UDDI specifies a protocol for querying and updating a common directory of Web service information. The directory includes information about service providers, the services they host, and the protocols those services implement. The directory also provides mechanisms to add metadata to any registered information.The UDDI directory approach can be used when Web service information is stored in well-known locations. Once the directory is located, a series of query requests can be sent to obtain the desired information. UDDI directory locations are obtained out of band, usually through system configuration data.Web service providers have various options for how they deploy UDDI registries. Deployment scenarios fall into one of three categories: public, extra-enterprise, and intra-enterprise. To support public deployments, a group of vendors led by Microsoft, IBM, and SAP host the UDDI Business Registry [UBR]. The UBR is a public UDDI registry that is replicated across multiple hosting organizations, serving as both a resource for Internet-based Web services and a testbed for Web services developers. While the public UDDI implementation has received the most attention to date, early adopters use the extra- and intra-enterprise approach more often. In these two deployment scenarios, a private registry is deployed by an organization and much tighter control over the types of information registered is possible. These private registries can be dedicated to only one organization or to groups of business partners. UDDI also defines protocols for replication between registries and for trust federation across deployments. Using these protocols further increases the number of deployment scenarios available to implementers.For all deployment scenarios, UDDI directories contain detailed information about Web services and where they are hosted. A UDDI directory entry has three primary parts: the service provider, Web services offered, and bindings to the implementations. Each of these parts provides progressively more detailed information about the Web service.The most general information describes the service provider. This information is not targeted at Web services software, but at a developer or implementer that needs to contact someone responsible for the service directly. Service provider information includes names, addresses, contacts, and other administrative details. All UDDI entries have multiple elements for multi-language descriptions.The list of available Web services is stored within a service provider entry. These services can be organized, depending on their intended use; they can be grouped into application area, geography, or any other scheme that is appropriate. Service information stored in a UDDI registry includes simply a description of the service and a pointer to the Web service implementations it contains. Links to services hosted by other providers, called Service Projections, can also be registered.The final part of a UDDI service provider entry is the binding to an implementation. This binding associates the Web service entry to the exact URI(s) to identify where the service is deployed, specifies the protocol to use for access, and contains references to the exact protocols that are implemented.These details are sufficient for a developer to write an application that invokes the Web service. The detailed protocol definition is provided through a UDDI entity called a Type Model (or tModel). In many cases, the tModel references a WSDL file describing the SOAP Web service interface, but tModels are also flexible enough to describe almost any kind of resource.For each provider or service registered in UDDI, additional metadata from standard taxonomies (such as NAICS [NAICS] and the older SIC industry codes [SIC]) or other identification schemes (such as an Edgar Central Index Key) can be used to categorize the information and improve search accuracy. The set of available taxonomies and identifier schemes is readily extensible as a part of any implementation, so it can be customized to support any specific geographic, industry, or corporate requirements.
