It was jointly felt by both Microsoft and IBM that the goals they had set out to achieve had been achieved. They had created a viable, workable system that would allow anyone to create UDDI registries of their own using the newest and tested specifications of UDDI. For businesses it was simple and easy to register their own business as well as list the web services they had to offer. In its wake there is no clear leader in the development of such a universal registry, although there are still UDDI registries to be found on the Internet.
Although a UDDI registry is not itself a book, it does often contain much the same information as a phone book, plus more. We can break down the information contained in a UDDI business registry into three categories. This is just like you would expect to find in any phone book or general company directory. Listed will be business name, address, person within the company to contact and most likely a phone number and or e-mail.
This is the most commonly used function of UDDI registries. Yellow Pages Yellow Pages, just like the Yellow Pages in the phone book, categorize companies based on business type and general services offered.
This is really no different at all from our normal Yellow Pages. It is here that the technical specifications of the web services offered by a company are listed, and through the Green Pages you are able to search out a business based solely on the web services they have available.
This is not the most commonly utilized branch of UDDI, however it is the heart of UDDI as it is what really sets it apart from just another company registry. Unfortunately for the average computer user it can be difficult to make use of UDDI registries these days, as they can be difficult to find. However the concept of UDDI has been proven: it can serve to provide a massive, easy to use directory listing companies and all of their web services in a manner that is easy to access and has great cross-platform interoperability.
A registry of all web service's metadata, including a pointer to the WSDL description of a service. As the time of writing this tutorial, Microsoft and IBM sites had implemented the 1.
Dozens of PIPs already exist. As an alternative to using the public federated network of UDDI registries available on the Internet, companies or industry groups may choose to implement their own private UDDI registries. It is also possible to set up private UDDI registries. For example, a large company may set up its own private UDDI registry for registering all internal web services. The business entity structure represents the provider of web services. Within the UDDI registry, this structure contains information about the company itself, including contact information, industry categories, business identifiers, and a list of services provided.
The business service structure represents an individual web service provided by the business entity. Its description includes information on how to bind to the web service, what type of web service it is, and what taxonomical categories it belongs to.
Every business entity and business service is uniquely identified in all the UDDI registries through the UUID assigned by the registry when the information is first entered. Binding templates are the technical descriptions of the web services represented by the business service structure. A single business service may have multiple binding templates.
The binding template represents the actual implementation of the web service. As a business service may have multiple binding templates, the service may specify different implementations of the same service, each bound to a different set of protocols or a different network address. Then, you can specify that a given business service implements that port type by associating the tModel with one of that business service's binding templates.
This is a relationship structure putting into association two or more businessEntity structures according to a specific type of relationship, such as subsidiary or department. The publisherAssertion structure consists of the three elements: fromKey the first businessKey , toKey the second businessKey , and keyedReference.
The keyedReference designates the asserted relationship type in terms of a keyName keyValue pair within a tModel, uniquely referenced by a tModelKey. A registry is of no use without some way to access it. The UDDI standard version 2. Service consumers use Inquiry Interface to find a service, and service providers use Publisher Interface to list a service. These define the fundamental UDDI data types through which all the information flows.
All of the Publisher interface operations require that a valid authorization token be submitted with the request. This step is equivalent to logging out of the system. Consider a company XYZ wants to register its contact information, service description, and online service access information with UDDI. Choose an operator with which to work. Each operator has different terms and conditions for authorizing access to its replica of the registry.
Register information about the business. Include as much information as might be helpful to those searching for matches. Use the inquiry APIs to test the retrieval of the information, including binding template information, to ensure that someone who obtains it can use it successfully to interact with your service. Fill in the tModel information in case someone wants to search for a given service and find your business as one of the service providers. Update the information as necessary to reflect the changing business contact information and new service details, obtaining and releasing a new authentication token from the operator each time.
0コメント