Web Services: UDDI Registry

Web Services: UDDI Registry
Dr.NaveenBansal Profile Pic
Dr.NaveenBansal,India,Teacher
Published Date:25-10-2017
Your Website URL(Optional)
Comment
Understanding Web Services- XML, WSDL, SOAP and UDDI Chapter 5. Finding Web Services: UDDI Registry After a Web service is set up, people must have a way to find and use the service. That's the purpose of the universal description, discovery, and integration (UDDI) registry, established by an industry consortium to create and to implement a directory of Web services. The UDDI registry accepts information describing a business, including the Web services it offers, and allows interested parties to perform online searches and downloads of the information. To contact a business to order something, you need a way to find information about that business: street address, telephone number, Web site, or Web service address. You can obtain the information directly from a business representative, perhaps in the form of a business card, handwritten note, or e-mail. You can also look up a business name in a telephone directory and obtain the address and telephone number. UDDI finds the Web service address and other information about a business Similarly, the information necessary for a program running on your computer to talk to a program running on someone else's computer over the Web must be published. Although UDDI is like a White Pages or Yellow Pages for Web services, it also enables developers to interact with UDDI at both design time and runtime. In short, UDDI resources can be considered part of the Web services architecture and infrastructure. UDDI is part of the Web services infrastructure When you want to interact with a business's Web service to check inventory availability before placing an order or to check for the right hotel, car, and flight before making a travel reservation, you need to be able to find and contact the business's Web service. UDDI supports Web services interface discovery If you don't know the business name or if you want to compare several suppliers' terms and conditions, the problem becomes greater, and the need for a generic search and discovery mechanism becomes more evident. The UDDI registry provides such a mechanism and is therefore important to the ultimate success of Web services. Figure 5-1 illustrates the public UDDI service hosted by IBM, Microsoft, SAP, HP, and potentially others. Each vendor provides a publicly accessible database containing business registry data, posted via SOAP requests to one of the vendor's data centers and replicated to the others. SOAP requests query the results of the posted updates to find information about businesses to be contacted, including metadata about a business's Web services. Figure 5-1. Multiple vendors host the public UDDI service. Page 110 Understanding Web Services- XML, WSDL, SOAP and UDDI UDDI operators host a replicated registry database The hosted databases are called operator sites, and UDDI programmers use SOAP APIs to interact with one or more of the sites. The operators do not charge for the basic UDDI service. Business data can contain pointers to Web services interface specifications, such as WSDL. Private UDDI services are often used to store a business's internal information, such as a list of available Web services. The UDDI Organization UDDI began as collaboration among Microsoft, IBM, and Ariba to promote the adoption and use of Web services standards. The companies founded UDDI.org and invited other companies to participate: some with founders' rights and others with advisory privileges. The companies invited as founders set the ground rules, defined the initial specifications and requirements, and decided on the eventual disposition of the work. The three original founders were also the original operators, or hosts, of the initial public UDDI repository. Later, Hewlett-Packard joined the project and replaced Ariba as a registry host site, and SAP joined as another operator. Other operators may join over time if they meet the terms and conditions set by the original operators and if the founding membership agrees. Covering UDDI Operator Costs Who will pay for the operator site costs over time? Today, IBM, Microsoft, HP, and SAP are absorbing the costs of running the public registry, but as UDDI evolves and gains acceptance, the cost issues will have to be addressed. For example, the sites already offer additional services beyond the base specification requirements, such as easy-to-use browser APIs. When UDDI is transferred to an independent organization or Page 111 Understanding Web Services- XML, WSDL, SOAP and UDDI authority, as planned when version 3 is completed, the independent organization will be faced with covering the costs of operating the public registry. It may be possible to charge for listings, as the telephone company charges for Yellow Pages listings, or to charge for added-value services. In any case, if a public registry like UDDI becomes required for Web services to be a truly established and successful part of everyday business operations on the Internet, it's not clear how the continuing cost of the service will be borne, or by whom. More than 300 companies joined UDDI.org in support of the effort to establish a Web-hosted business directory of services. Fifteen of the companies form the core Working Group that is responsible for setting the strategic course of the project and for resolving conflicts and making decisions. The remainder are members of the Advisory Group, which allows a company to review and to comment on specification drafts before they're made public and, on approval or invitation of one or more of the Working Group members, to join one of the specification drafting teams. More than 300 companies belong to UDDI.org The Working Group members have the final say on organizational issues and specification decisions, but small teams, including companies not in the core membership, perform the work on specifications. The specifications developed by the teams are sent for review and approval to the entire membership before they are published. UDDI v2, on which this chapter is based, contains enhancements, such as publishing the operator and replication specifications, improving the query capability, and providing internationalization support. Working Group members have the final say UDDI.org announced its intention to complete v3 of the specifications and to submit them to a standards body, perhaps W3C or OASIS, for further maintenance and enhancement. The founding members did not submit the work to a standards body originally, because it's more efficient and effective to develop the specifications in a private consortium first; more progress could be made more quickly that way, they said. Also, UDDI is unique as a specifications development group inasmuch as part of the core membership also hosts the public service based on the specifications. UDDI v3 specifications will be submitted to an independent standards body The operators run both a test site and a production site, allowing Web services providers and businesses to test their UDDI clients before posting real information to the production database. Of course, before being allowed to post the real information to the production database, a business needs to be authorized to do so, and the data needs to be validated. To prevent spoofing and wiretapping, communication with UDDI requires encrypted messages in the form of HTTPS. Among the work items for UDDI 3 is improved security. Operators run both test and production sites Page 112 Understanding Web Services- XML, WSDL, SOAP and UDDI Ongoing Role for the Founders? What happens to the host, or operator, part of the organization once the specifications are placed under the control of a standards organization: Will the operator sites also be placed under independent control? The issue is related as much to the disposition of intellectual property in the form of specifications and working agreements as it is to the disposition of real property in the form of computers, databases, and network equipment dedicated by private companies to a public function. Eventually, it seems clear, a public Web services registry is likely to require government regulation to ensure independent control and open access. The Concepts Underlying UDDI The public UDDI registry works a little like the Internet domain name service (DNS). Businesses can register with any of the hosts—IBM, HP, SAP, or Microsoft—and the information they provide will be placed into the database at that host site. At regular intervals, at least nightly, all information placed into one of the host site databases is replicated to the other host site databases, ensuring that they are all kept in synch. Users requesting data about a business can then receive the same information about a registered business from any of the host databases. When it needs to update the data, however, a business must return to the original site to which the data was placed and execute the update function. Registry replication works similarly to DNS For obvious reasons, security is a primary concern of UDDI.org members. Businesses are authorized to update information by one of the operators and therefore must return to the original operator to change or to delete any information they posted. Businesses wishing to register with UDDI must first obtain authorization to do so and must be approved by at least one of the operators. Approval means sending to the business an authorization token that allows the business to log onto the UDDI site and to store or to update data. Authorization to update the registry is handled by the operators individually; login information from one operator will not work for another. For all practical purposes, someone registering information with UDDI has to choose one of the operators and stick with that operator. Security is a prime concern Another primary concern is the quality, or validity, of the data. Someone has to ensure that the business being registered is a real business; that the business name, ID number, category information, phone number, Web page, and street address are correct; and that the business category and geographical information are correct. UDDI v2 is set up to allow third parties to do this and does validate category data. Data validity is another primary concern Page 113 Understanding Web Services- XML, WSDL, SOAP and UDDI UDDI has two main parts: registration and discovery. The registration part means that businesses can post information to UDDI that other businesses can search for and discover, which is the other part. Businesses and individuals interact with UDDI by using SOAP APIs or one of the user interfaces provided by the operators or other Web services vendors. UDDI operators post WSDL descriptions of their Web services for registration and discovery. UDDI provides separate WSDL files for registration and discovery services, using its own XML document format. The two main parts of UDDI are registration and discovery Some UDDI SOAP APIs are used for inserting information into the registry; others, for browsing and retrieving specific information from the registry. UDDI APIs require a specific subset of SOAP; that is, UDDI does not use the optional serialization format and some other features defined in the SOAP specification. (See UDDI Support for SOAP and Unicode, later in this chapter for further information.) SOAP APIs are used to submit and to retrieve data How UDDI Works UDDI information is often described as being divided into three main categories of business information: n White Pages: Business name and address, contact information, Web site name, and Data Universal Numbering System (DUNS) or other identifying number. n Yellow Pages: Type of business, location, and products, including various categorization taxonomies for geo-graphical location, industry type, business ID, and so on. UDDI contains White Pages, Yellow Pages, and Green Pages information Issues with UDDI Acceptance Part of the problem that UDDI has to overcome is trust. In other words, will businesses really trust private vendors to host and operate such a thing? Another issue is standardization. In other words, will UDDI really become a recognized standard? Usefulness of the model may also be questioned, meaning that the proposed categorization of businesses, business information, and Web services interface information may not prove to be useful. Finally, there is a thorny legal issue with respect to doing business over the Web, including Web services. Is a business-to-business interaction over the Web equivalent legally to a paper-document exchange using a fax machine or regular mail? Another fundamental question confronting UDDI and its users is: What does it mean that businesses are categorized? Does it somehow relate to contact information? Isn't the most important thing what a business sells rather than its geographical location? Is the location of a business in a physical sense as relevant as what it supports in terms of interactions over the Internet? With all the outstanding questions about proper and useful categorization, it's likely that the full realization of UDDI's potential is several years away if ever. Page 114 Understanding Web Services- XML, WSDL, SOAP and UDDI n Green Pages: Technical information about business services, such as how to interact with them, business process definitions, and so on. A pointer to the business's WSDL file, if any, would be placed here. Information in this category describes a service's features/functionality, including a unique ID for the service. This category is quite new and specific to the Internet. The data structure of UDDI is expressed using complex types in XML schemas. These schemas allow for extensibility and great flexibility in the data stored for a particular business or entity. UDDI data structures are expressed using XML schemas Classification and identification information is useful for searching and retrieving lists and specific details about businesses. Businesses can add any number of classifications to their registrations for the purpose of assisting searches. Classification and identification information includes such things as IRS industry codes, Dun and Bradstreet DUNS numbers, product codes, geographical codes, and so on. Classifications and identifications are handled via property bags, or unstructured data sequences, in which virtually any type of classification and identification information can be stored. UDDI stores classification and identification information Flexible and Extensible Data Structures The UDDI data structure provides so many options and extensions that it's almost impossible to predict the level of consistency that will be achieved among entries for different businesses. In other words, it may be very difficult to predict the type of detail available for a given entry. If UDDI is ever to succeed, the data will have to be normalized and regularized a good deal more than it is. Although UDDI is addressing this problem by publishing best-practices documents and providing wizards for the registration process, the problem remains. Classification taxonomies for category information include the following: • North American Industry Classification System (NAICS) — www.census.gov/epcd/www/naics.html • Universal Standard Products and Services Classification (UNSPSC)—www.unspsc.org • International Organization for Standardization (ISO) 3166— www.din.de/gremien/nas/nabd/iso3166ma (geographical regions, codes for countries, and so on) Operator sites validate category information for industry codes via NAICS, product and service classifications via UNSPSC, and geographical codes via ISO 3166. However, including information on any or all of these categories is optional, as is checking this data when registering. Other classification taxonomies can be used, but they are not checked for validity. Operators validate some category information Page 115 Understanding Web Services- XML, WSDL, SOAP and UDDI UDDI v2 supports checked and unchecked classifications and identifications. Although UDDI does not check or validate classification and identification information beyond NAICS, UNSPSC, and ISO 3166, UDDI.org does support a program that is meant to encourage third parties to provide such an ancillary service. Registered data can be checked or unchecked UDDI Data Model UDDI registration information is comprised of the following five data structure types: n businessEntity, the top-level structure, describing the business or other entity for which information is being registered. The other structures are related via references from this structure. n businessService, the name and description of the service being published. n bindingTemplate, information about the service, including an entry-point address for accessing the service. n tModel, a fingerprint, or collection of information uniquely identifying the service specification. This data structure also supports top-level searches. n publisherAssertion, a relationship structure putting into association two or more businessEntity structures according to a specific type of relationship, such as subsidiary or department of. UDDI identifies five basic data structures When the data is submitted for the first time, the UDDI operator assigns a unique key that identifies each of these data structures. The unique keys take the form of universally unique identifiers (UUIDs), sometimes called globally unique identifiers (GUIDs). The UUID format is derived from the Open Software Foundation (now part of the Open Group) Distributed Computing Environment; formalized now as ISO/IEC 11578: 1996 Information Technology—Open Systems Interconnection—Remote Procedure Call (see also www.iso.ch/cate/d2229.html). UDDI operators assign unique keys for data structures A UUID generator uses a complex algorithm, which takes into account factors, such as the current date and time, to produce a hexadecimal number that has a statistical guarantee of uniqueness. The odds of producing a duplicate number, in other words, are so great as to be impossible in practice. An example of a UUID is C90D731D-777D-4130-9DE3-5303371170C2. Figure 5-2 illustrates the basic UDDI data model, in which data related to the businessEntity structure can be returned as results to a query. Relationships among data structures are established via key references. Figure 5-2. The basic UDDI data model is a containment hierarchy. Page 116 Understanding Web Services- XML, WSDL, SOAP and UDDI In Figure 5-2, the underlined fields, such as businessKey, are required elements; that is, a request to store data will be rejected if these elements are not present, although in some cases a required element can contain zero entries. The data model is a containment hierarchy in which businessEntity is the root, or top-level, structure. The publisherAssertion schema was added for UDDI v2 to allow multiple businessEntity entries to be placed in relation with one another—for example, to accommodate large companies wishing to register their various divisions or subsidiaries. The UDDI data model has required elements The arrows in Figure 5-2 illustrate the elements that are used to establish the relationships. The entry in businessServices in the businessEntity schema is optional; if present, it contains one or more serviceKey fields containing key values that are present in associated businessService entries. Relationships are established among the data structures Similarly, the bindingTemplate element in the structure businessService contains bindingKey entries that reference any associated bindingTemplate structures. The bindingTemplate in turn references the tModel structure. Information in the bindingTemplate and the tModel structures can be combined to find a complete Web service interface. Generic Data UDDI is designed to accept virtually any type of Web services description, including industry- specific description languages. WSDL provides a general-purpose language for describing the interface, protocol bindings, and deployment details and as such is complementary to UDDI but not required by it (see Using WSDL with UDDI later in this chapter). In other words, the data structures established by UDDI not only predate WSDL but also are designed to be completely Page 117 Understanding Web Services- XML, WSDL, SOAP and UDDI extensible to contain and to reference any type of contract agreement between two parties in a distributed or networked exchange of information. UDDI accepts virtually any type of data Quality of UDDI Data Is a Question Today, even though UDDI is alive and in production, the quality of the data does not fullfill the UDDI vision. Despite provisions for third parties to work with UDDI.org members to establish validation services, the organization itself does not provide more than basic validation of category information. In other words, no mechanism has been established to ensure that the data going in is sufficient to create a truly successful Web services registry. The XML schema structures defined for UDDI do not prescribe any underlying storage format. That is, the way in which the data is sent to a UDDI operator may be different from the way in which it is stored. This doesn't matter as long as the XML structure can be recreated from the persistent database storage format. (This is consistent with the whole XML approach to data independence, which relies on mapping into and out of XML structures that are independent from the way in which data is represented in the underlying programs and databases.) The XML schemas don't prescribe any underlying storage format As shown in Figure 5-3, the UDDI data structures provide several types of information, including contact, identification, and category, to be stored in association with the main businessEntity structure. Each of these is handled via repeating types of information sequences contained within the businessEntity structure. The descriptive information is basically the information that can be searched for a match and for which service information can be returned via reference to the tModel keys. Figure 5-3. UDDI manages several types of descriptive information. Page 118 Understanding Web Services- XML, WSDL, SOAP and UDDI The Business Entity The top-level structure (businessEntity) is where most queries start. Depending on the type of information being searched, however the queries will usually also include one or more identifiers or category keys. Queries may also start with other entities, however. Here is an example. The business entity structure is where queries and registries usually start element name = "businessEntity" complexType sequence element ref = "discoveryURLs" minOccurs = "0"/ element ref = "name" maxOccurs = "unbounded"/ element ref = "description" minOccurs = "0" maxOccurs = "unbounded"/ element ref = "contacts" minOccurs = "0"/ element ref = "businessServices" minOccurs = "0"/ element ref = "identifierBag" minOccurs = "0"/ element ref = "categoryBag" minOccurs = "0"/ /sequence attribute ref = "businessKey" use = "required"/ attribute ref = "operator"/ attribute ref = "authorizedName"/ /complexType /element The preceding illustrates the XML definition for the top-level businessEntity structure. The schema defines a complex element sequence constrained by the use of attribute names and usage qualifiers for repetition and required characteristics. BusinessKey is required, and UUID keys are assigned when the structures are created. The minimum necessary to create a businessKey entity, therefore, is the business name, and queries typically start with that. Does UDDI Support Too Many Options? With so many optional and extensible fields, UDDI is very easy to use and can contain virtually any type of information. But with all the flexibility and extensibility, how can a real pattern of registration and searching be established to support meaningful search and discovery? For example, the only required field when registering is a business name. Searches on names are difficult to get exactly correct because of spelling and other attributes of names, such as Inc. or PLC, that can be included. So it's almost certain that someone will have to review a list of names manually to pick out the right one. In addition, there's no required format for contact information or for identifying information or category information; in fact, there isn't any way to ensure consistency or appropriateness of search information. UDDI as a concept holds great promise for Web services, and the organization is hard at work addressing the various issues. The problem UDDI is trying to solve is tremendous, and one of great potential benefit. The Binding Template The binding template provides information for physically accessing a Web service or other type of service registered with UDDI. A business may register multiple binding templates for a given business service and identify different access points for that service, if appropriate or useful. Page 119 Understanding Web Services- XML, WSDL, SOAP and UDDI A binding template contains the service access point, or URL type The access point types in the bindingTemplate structure include the following URL types: n mailto: n http: n https: n ftp: n fax: n phone: n other: The information following the type has to be formatted correctly for the type. For example, the mailto: type requires a valid e-mail address; the http: type, a valid URL format; and phone: a valid telephone number. In this way, a business can provide the right access type for various contact mechanisms for the same or different services. No validation is done to ensure that something exists at the other end of the address; in most cases, however, this is no more of a concern than the general concern over the validity of UDDI data. Information has to be correctly formatted for each binding type The tModel In UDDI terms, a tModel is the mechanism used to exchange metadata about a Web service, such as the Web service description, or a pointer to a WSDL file. The UDDI definition of a Web service is much broader than the examples shown in this book. The UDDI registry aims to be general enough to support any type of service accessible over the Internet. So that's why UDDI doesn't use only WSDL. If WSDL becomes popular and widely accepted, perhaps most tModels will use WSDL. For now, however, other protocols can be considered Web services by UDDI's definition, at least in terms of what's acceptable to put in a tModel. A tModel uniquely identifies a Web service UDDI also predates WSDL. In this book, WSDL has been used as an integral part of a Web services definition, but UDDI defines a Web service a bit differently and more broadly. UDDI defines Web services as "technical services that are exposed for either private or general use. Examples include purchasing services, catalog services, search services, and shipping or postal services exposed over transports, such as HTTP or electronic mail." Business-to-business protocols, such as RosettaNet and ebXML, can be considered Web services by UDDI's definition, although neither of them uses WSDL. UDDI v1 predates WSDL Page 120 Understanding Web Services- XML, WSDL, SOAP and UDDI A tModel is roughly the UDDI equivalent of WSDL but is broader and can include pointers and references to services using addresses other than URLs and transports other than SOAP. Each tModel is assigned a UUID key by an operator when initially stored. The descriptive information stored in association with the main tModel structure is intended to help ensure that duplicate services can be identified. (Using WSDL with UDDI is discussed later in this chapter.) WSDL is compatible with UDDI A tModel is designed to identify uniquely interface specifications for Web services—in the broad sense in which UDDI defines them—and to help allow them to be discoverable. A tModel provides alternative entry points into the UDDI data structures in order to discover specific services and to link them to the businesses that provide them. It's also likely that multiple businesses will end up exposing the same service. Once firmly established, Web services are not going to be unique or customized to a particular business. A tModel can be shared by multiple businesses The tModels, representing keyed metadata about a service, are intended to ensure compatibility of interfaces or services across multiple registry entries. To be useful, a tModel should contain a pointer to a place where the user can obtain more information about the service. Another intended function of tModels is to support registry searches for a specific service. For example, suppose that your business wants to access a catalog service or a credit card validation service. The UDDI APIs support searching for specific service definitions and listing the companies that offer compatible services. If you can obtain a tModel key value associated with the specific type of service you want, you can search UDDI for companies that offer it. A tModel is intended to be a separate, independent entity referenceable by one or more businesses that offer a given Web service. In other words, the UDDI designers assumed that a Web service might be a generic or general-purpose service that more than one business or entity would provide. Therefore the tModel is not specific to a given business or entity and is a searchable structure in its own right, linked to one or more businesses or entities. The tModel assumes that Web services are separately referenceable entities The reverse is also true; a business or an entity can reference multiple tModels. In the short term, it seems likely that most businesses will expose unique Web services, but over time, it seems likely that some companies will host services for other companies, and perhaps multiple companies will get involved in the Web services hosting business. UDDI defines tModels to look up its own services, including tModels that define the inquiry and publisher APIs for interacting with the registry and taxonomy maintenance APIs. For example, tModels are defined for NAICS, UNSPSC, and ISO 3166 classification taxonomies. These examples illustrate the use of a tModel as an abstract namespace definition. Page 121 Understanding Web Services- XML, WSDL, SOAP and UDDI UDDI SOAP APIs The UDDI APIs are divided into those that register information and those that search the information in the registry. The registration APIs are used by publishers, that is, by businesses and/or business agents that send requests to enter the information into UDDI. The search APIs are used by registry consumers to find business information by category and to retrieve detailed information about one or more individual businesses that meet the search criteria. UDDI APIs are separated into publisher and consumer APIs In general, APIs for registering information include saving and updating current information and deleting old information. APIs for searching information include returning summary information about a group of entries or returning complete information for a specific single entry. Anyone wishing to use any of the publisher APIs must first apply for an authentication token from an operator. Each operator distributes authentication tokens using its own mechanism; so in practice, a publisher interacts with only one operator. A publisher therefore signs up with an individual operator and is granted credentials for logging on and using the publisher APIs. The publisher APIs are required to be used over HTTPS (SSL v3.0) for encryption on the wire. Publishers must be authorized by operators Versioning is accomplished via namespaces. For example, the following is an attribute on the v2 APIs to indicate that the v2 APIs are being used: xmlns="urn:uddi-org:api_v2" Namespace revisions indicate UDDI API versions Publisher and consumer SOAP APIs are available via HTTP POST only. APIs support Unicode, which requires the use of UTF-8 encoding. Publishers can register business and other descriptions using multiple human languages. UDDI accepts HTTP POST operations only Inquiry APIs Using one or more search criteria, the inquiry APIs browse registry information and obtain specific information about a registered business or service specification once the proper unique key is obtained. Inquiry APIs support browsing and drilling down on specific entries Page 122 Understanding Web Services- XML, WSDL, SOAP and UDDI Various search criteria are used to find one or more matching records. Typically, a search starts with a generic request that returns a list of businesses that match a given category or identification string. Then other inquiry APIs are used to return service and/or contact information for a given specific business. Inquiries can be done using matches on business names or identifiers or using category information, such as industry type or geographic location. Inquiry APIs support varied criteria Inquiry APIs are as follows: n find_binding, locates specific binding information and returns a bindingDetail message that includes the access point, by URL type, for the service n find_business, the main API for the initial search, finds information about one or more businesses and returns a business list message n find_relatedBusinesses, finds businesses related to the business key and returns a business list message; checks for subsidiary or other departments for a given business n find_service, finds and returns specific services listed for a specific business n find_tModel, finds and returns tModel structures, providing a way to search the registry for matching services n get_bindingDetail, finds and returns bindingTemplate information sufficient for invoking a service hosted by a specific business; returns a bindingDetail message n get_businessDetail, gets full detail on a specific registered business and returns a businessDetail message, usually a second inquiry once a list of matching businesses is returned by a previous inquiry n get_businessDetailExt, finds and returns an extended businessDetailExt message; that is the same as get_businessDetail but with extended information defined for after v1 n get_serviceDetail, finds and returns all information about a given set of registered business service information; returns a serviceDetail message n get_tModelDetail, gets full details for a set of registered tModel data; returns a tModelDetail message Inquiry APIs return no values if there's no match for one of the search keys. The APIs include an option to set a maximum number of rows to be returned and a flag to indicate that more rows exist than can be returned. Wildcard searching is available on the find_business API name parameter. Inquiry operations return blank messages if there's no match for any search value The find_business API, the main search API, can search via name, identifiers, categories, or tModel references and can also search for URLs. Up to five name values are supported for a search. Usually, the first search returns a list of matches to one or more of the criteria. Page 123 Understanding Web Services- XML, WSDL, SOAP and UDDI The find_service API can be used to find specific services that meet specific criteria. You can browse by name on a service, get the UUID for the service, and pass it back in to the find_service API to get the specific service entry. Find specific service information The binding-detail API gets the information you need to call a service. The information can be cached and refreshed as needed. Extension (Ext) APIs are available for compatibility when things are added. For example, get_businessDetailExt returns the same information as get_businessDetail, plus more info: extensions to UDDI for v2, in other words. Obtain the binding detail to invoke the service Sometimes, the results of one query feed the input for another query. For example, get_businessDetail might return a tModel key from the tModelInstanceInfo associated with the business information; then the next call can use the tModel key to obtain a specific tModel record. Finally, the tModel can be linked to one or more business entity structures to obtain the information necessary to access the service. No authentication is required for inquiry APIs. No wire encryption is used. Inquiries don't need security Publisher APIs Publisher APIs are used to store, to update, and to delete or hide information in the registry. Like all APIs that store data, the data being stored ideally takes typical subsequent query operations into account. In other words, appropriate data has to be stored to allow the inquiries to produce meaningful results. Publisher APIs store, update, and delete registry information Passing a blank UUID key indicates that the data is being stored for the first time. New or different information with the same UUID replaces the old information. Relationship information can be changed by making changes to the keys that define the relationship information. When businessEntities are registered, the operator site creates a URL that can be used to get the element being registered by using an HTTP GET operation. The publisher APIs allow any number of classification codes to be stored for a business. Classifications include category codes for a business or geographical information. When registering information, a business or an agent has the option of asking for the categorization Page 124 Understanding Web Services- XML, WSDL, SOAP and UDDI information to be checked or to remain unchecked, that is, for UDDI to accept any categorization data the business or agent wants to store. Any number of classification codes can be stored UDDI operators hope that third parties will develop and provide checking services. If the checked option is used, only the name is stored unless the category information checks out. Data can be checked when stored Following are some publisher APIs: n add_publisherAssertions, adds relationship assertions, or puts one or more businesses into relationship, such as departments or subsidiaries n delete_binding, removes a bindingTemplate n delete_business, deletes a registered businessEntity n delete_publisherAssertions, deletes relationship information n delete_service, deletes a registered businessService 1 n delete_tModel, hides a tModel 1 Because existing references might use them, tModels are not deleted. Hidden tModels can be reactivated by invoking the saved tModel with the original data. n discard_authToken, informs the operator with which the business or the agent is registered that the authentication token is not valid anymore; that is, the business or the agent is discarding the token or is not going to use it anymore n get_assertionStatusReport, a report, primarily for operator use, to check and to help validate registered relationships n get_authToken, requests an authentication token from an operator site; a prerequisite for using other publisher APIs n get_publisherAssertions, lists active assertions for a given publisher to define relationship information n get_registeredInfo, provides a summary of all information registered on behalf of a specific user, is operator specific, and based on authentication token n save_binding, either stores a new or updates an existing bindingTemplate n save_business, either stores a new or updates an existing businessEntity n save_service, either stores a new or updates an existing businessService n save_tModel, either stores a new or updates an existing tModel n set_publisherAssertions, save new assertions or replace existing ones; all elements are required Operators can impose space limits to prevent businesses from registering too much information. Such limits are part of the negotiation with the operator you choose, but the spec calls for these limits for a new user, per account granted: n Business entity per account: 1 n Business service definitions: 4 Page 125 Understanding Web Services- XML, WSDL, SOAP and UDDI n Binding templates: 2 n tModels: 100 n Publisher assertions or business relationships: 10 n Maximum message size: 2MB Operators are allowed to impose resource limits on publishers Each registered bindingTemplate must contain a valid serviceKey that corresponds to a registered businessService controlled by the same account, that is, the same authentication key. It's possible to change a bindingTemplate relationship, however If a businessService or a bindingTemplate is contained within more than one businessService, the relationships are determined by processing order: the final operation redefines the relationships for the registered information. Binding information can be moved from one relationship to another, although UDDI does not provide any validation of the resulting change. In other words, UDDI can't validate or enforce the meaning or significance of changing relationships among businesses and services. A service can be linked to more than one business UDDI allows relationships to be defined among businesses but has no way to reconcile, or check, duplicate entries for the same business, as when a subsidiary registers separately from the parent company. The validate_values API is also part of the publisher APIs but is reserved for operator use. The operator uses the API to call out to a third party with which it has agreed on using as a validation service for additional categorization taxonomies and identification schemes. This allows UDDI data categorization to be validated after a save or an update operation on the UDDI nodes when further details are required. Subsidiaries can be linked to parent companies Usage Scenario Imagine that the Skateboots Company wants to register its contact information, service description, and online service access information with UDDI. The following steps are necessary: 1. Choose an operator with which to work. Each operator has different terms and conditions for authorizing access to its replica of the registry and may provide some value-added services on top of the basic UDDI services. Also, whenever you need to update or to modify the data you've registered, you have to go back to the operator with which you entered the data. 2. Build or otherwise obtain a UDDI client, such as those provided by the operators. 3. Obtain an authentication token from the operator. 4. Register information about the business. Include as much information as might be helpful to those searching for matches. 5. Release the authentication token. 6. 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. Page 126 Understanding Web Services- XML, WSDL, SOAP and UDDI 7. 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. 8. Update the information as necessary to reflect changing business contact information and new service details, obtaining and releasing a new authentication token from the operator each time. The examples in the following sections show how the Skateboots Company would register its information and how a distributor interested in carrying the Skateboots line might find information about how to contact the company and place an order, using the Skateboots.com Web services. Skateboots gets clearance from one of the operators Updating the Registry After obtaining an authentication token from one of the operators—Microsoft, for example—the Skateboots.com developers decide what information to publish to the registry and use one of the UDDI tools provided by Microsoft. If necessary, the developers can also write a Java, C, or VB.NET program to generate the appropriate SOAP messages. Here is an example. Skateboots can register and be discovered POST /save_business HTTP/1.1 Host: www.skateboots.com Content-Type: text/xml; charset="utf-8" Content-Length: nnnn SOAPAction: "save_business" ?xml version="1.0" encoding="UTF-8" ? Envelope xmlns="http://schemas/xmlsoap.org/soap/envelope/" Body save_business generic="2.0" xmlns="urn:uddi-org:api_v2" businessKey="" /businessKey name Skateboots, Inc. /name description You know, like the ones in Batman and Robin . . . /description identifierBag ... /identifierBag ... /save_business /Body /Envelope 2 This example illustrates a SOAP message requesting to register a UDDI business entity for Skateboots Company. The key element is blank because the operator automatically generates the UUID key for the data structure. Most fields are omitted for the sake of showing a simple example. 2 Note that the examples in this chapter use SOAP v1.1. Page 127 Understanding Web Services- XML, WSDL, SOAP and UDDI Skateboots can always execute another save_business operation to add to the basic information required to create a business entity. Most likely, Skateboots Company will want to include one or more identifiers and category IDs and link its two Web services—for PreSeason and In-season orders—to tModel information. Retrieving Information After Skateboots Company has updated its UDDI entry with the relevant information, companies that want to become Skateboots distributors can look up contact information in the UDDI registry and obtain the service descriptions and the access points for the two Web services that Skateboots.com publishes for online order entry: preseason bulk orders and in-season restocking orders. Customers retrieve the information POST /get_businessDetail HTTP/1.1 Host: www.skateboots.com Content-Type: text/xml; charset="utf-8" Content-Length: nnnn SOAPAction: "get_businessDetail" ?xml version="1.0" encoding="UTF-8" ? Envelope xmlns="http://schemas/xmlsoap.org/soap/envelope/" Body get_businessDetail generic="2.0" xmlns="urn:uddi-org:api_v2" businessKey="C90D731D-777D-4130-9DE3-5303371170C2" /businessKey /get_businessDetail /Body /Envelope This example illustrates a sample SOAP request to obtain business detail information about the Skateboots Company. Once you know the UUID, or key, for the specific business that's been registered, you can use it in the get_businessDetail API to return specific information about that business. Normally, to refine the initial search, you might send a message to UDDI containing the business name or a partial name with a wildcard to see whether you can get any matches. businessList generic="2.0" operator="uddi.sourceOperator" truncated="false" xmlns:="urn:uddi-org:api_v2" businessInfos businessInfo businessKey="C90D731D-777D-4130-9DE3- 5303371170C2" nameSkateboots Inc./name serviceInfos serviceInfo serviceKey="D90D731D-777D-4130- 9DE3-..." namePreSeason Orders/name /serviceInfo serviceInfo serviceKey="E90D731D-777D-4130- 9DE3-..." nameIn-season Orders/name /serviceInfo Page 128 Understanding Web Services- XML, WSDL, SOAP and UDDI /serviceInfos /businessInfo businessInfo ... more Skateboot manufacturers /businessInfos /businessList The preceeding example illustrates a sample message that might be returned from any of the UDDI operators on receipt of the find_business request. The service information—the serviceKey—is then used to locate the binding information that is needed to interact with the preseason and in-season Web services. Another approach would have been to search for the tModel definition of the service, using identifier or category search IDs. But in this case, the distributor knows that only one company manufacturers the particular skateboots it wants to sell, so it's unlikely that a generic service exists for ordering from the factory. Alternatively, search using the tModel Figure 5-4 illustrates sample information stored in UDDI for the Skateboots Company's Web services after it's done registering. A more complete entry would include identifiers and category taxonomy information, which also contain pointers to tModel structures, providing an alternative traversal path for obtaining service information. Figure 5-4. This sample shows a partial UDDI entry for Skateboots.com. The sample in Figure 5-4 shows a straightforward traversal path, starting with an inquiry on the businessEntity for Skateboots and from that entry is able to find the contact information— Page 129

Advise: Why You Wasting Money in Costly SEO Tools, Use World's Best Free SEO Tool Ubersuggest.