Keep up with the constant development of norms
Unified description, Discovery, and integration (Universal Description, Discovery, and Integration,uddi) projects continue to enrich the toolset that enterprises use to represent WEB services and build their models in a UDDI business registry. This article describes UDDI and its facilitation role in the development of WEB services. You can learn how UDDI works and discover the new features that are coming up with the UDDI specification.
0 Reviews:
Tom Bellwood ([email protected]), senior technician, IBM
July 01, 2002
UDDI projects encourage WEB services to interoperate and adopt each other. It is a partnership between business leaders, which was first established by IBM, Ariba, and Microsoft. More than 300 companies are now participating. UDDI provides a set of standards-based specifications for describing and discovering services, and also provides a set of Internet-based implementations. UDDI continues to grow rapidly and has won the support of the industry. This specification is developed quickly because there is a rapid implementation behind the support, not only to prove the idea, but also to further improve the norms provide a rich practical basis.
UDDI solves a large number of problems that the enterprise encounters. First, it helps to broaden the scope of business-to-business interactions and simplifies the process of interaction. For those who need to build many relationships with different customers, each has its own set of standards and protocols, and UDDI supports a highly adaptable service description that can use almost any interface. For a flower shop located in Australia, although it is very desirable to enter all markets in the world, but without knowing how to succeed, UDDI provides a way to achieve this goal. The specification allows the enterprise to publish the services it provides in the registry, so that the enterprise and services become efficient and simple.
For business-to-business trading place providers, they need to obtain disaggregated data from vendors in this industry, and their relationships with billing services, packers, transporters, insurers, and so on, and UDDI allows for the dynamic discovery and integration of related WEB services into aggregated businesses. UDDI provides a one-stop search for information about corporate and e-services. Publishing Enterprise and service information in UDDI enables other enterprises to access this information in a wide range of areas.
UDDI is based on out-of-the-box standards, such as Extensible Markup Language (extensible Markup Language,xml) and Simple Object Access protocol (easy objects, Access Protocol,soap). All compatible implementations of UDDI support the UDDI specification. Public norms are developed by institutional members in an open and inclusive process. The aim is to make and implement the three successive versions of this specification, and then transfer ownership of future developments to an independent standard organization. The UDDI version 1 specification was released in September 2000 and version 2 was released in June 2001. Version 3 is also under development and is expected to be released by 2002. Version 1 lays the foundation for the Registry, and version 2 adds features such as enterprise relationships, and version 3 goes on to address issues in the important areas of ongoing WEB services development, such as security, improved internationalization, interoperability between registries, and various improvements to the API to further improve the tools.
Figure 1. Tiered Web Service protocol stack for UDDIAs shown in Figure 1, UDDI is contained within the complete Web services stack and is one of the main components of the protocol Stack Foundation, enabling the creation, description, Discovery, and invocation of Web services.
UDDI is built on top of the network transport layer and the SOAP-based XML message transport layer. Service description languages such as Web Service Description Language (Web Services Description LANGUAGE,WSDL) provide a unified XML vocabulary (as with the interactive data Language, Interactive IDL) for describing Web services and their interfaces. You can use the ability to add hierarchies to address system reliability and availability by using the Web Services workflow description, security, management, and quality of service features of the Web Service process language (Web Services flow LANGUAGE,WSFL).
Back to top of page
How UDDI WorksThe UDDI registry contains a description of the services that the enterprise and enterprise support can be accessed through procedural means. It also includes references to the industry-dependent specifications that WEB services support, taxonomy definitions (for categories that are important for businesses and services), and identity systems (for identities that are important to the enterprise). UDDI provides a programming model and schema that defines the rules for communicating with the registry. All APIs in the UDDI specification are defined in XML, wrapped in a SOAP envelope, and transmitted over HTTP.
Figure 2. The flow of UDDI messages between the client and the registryFigure 2 illustrates the transfer of UDDI messages, which are transmitted from the client's SOAP request through HTTP to the registry node and then back again. The SOAP server of the registry server receives a UDDI SOAP message, processes it, and then returns the SOAP response to the client. As far as the Registry Ordinance is concerned, requests made by the client to modify data must ensure that it is a secure, authenticated transaction.
Figure 3. How UDDI WorksFigure 3 illustrates how to send data to a UDDI registry and how customers can discover and use this information. The UDDI registry is based on the data provided by the customer. Several steps are required to make the data available for use in UDDI. As shown in step 1th, when software companies and standard organizations define the specifications for an industry or enterprise registered in UDDI, they start publishing useful information to the registry. These specifications are called technical models or, more commonly, TModel .
In the 2nd step, the company also registers a description of its business and the services it provides. As shown in step 3rd, the UDDI registry assigns each entity a unique identifier in the program, called the unique Universal identifier (unique Universal identifier,uuid) key, so that all of these entities can be kept abreast of the situation. The UUID key must be unique and will never change in a UDDI registry. These keys look like a formatted hexadecimal random string (for example, C0B9FE13-179F-413D-8A5B-5004DB8E5BB2). You can use these keys to refer to the entities associated with them. The UUID key created in a registry is only valid in the context of that registry.
In the 4th step, other types of clients such as electronic Trading Places (e-marketplace) and search engines and commercial applications (for example, Web services aggregated based on workflows) use the UDDI registry to discover the services they are interested in. Then another enterprise can invoke these services, making it easy to dynamically integrate, as described in step 5th.
The data in the UDDI registry can be conceptually divided into four categories, each of which represents one of the top-level entities of UDDI. Each of these entities specifies its own UUID, which can always be found in the context of the UDDI registry, using this identifier:
We can divide the registration information of enterprises and services into the following three groups: White pages, Yellow Pages and green pages.
White Pages represent basic information about the business, such as the name of the business, the description of the business scope, contact information, and so on. It also includes any identifier for the enterprise, such as Dun & Bradstreet d-u-n-s® number.
Yellow Pages Information enables you to find a larger range of businesses or services registered in a registry by supporting the categorization of categories that are generated by using a variety of taxonomy systems with classification capabilities. Such classification can not only be associated with enterprises and their services, but also associated with TModel. One or both of the white and Yellow pages are available, the value of the registry entry is limited for discovering and using the service through the program. For this reason, information about how and where to invoke a service in a program is necessary, and the green page provides such information.
A green page is a binding information that is associated with a service and provides pointers to the technical specifications that these services implement and to the different discovery mechanisms that point to file-based URLs.
A UDDI registry consists of one or more implementations of the UDDI specification, which can interoperate to share registry data. There is a special UDDI registry that consists of a set of publicly accessible UDDI implementations called nodes. They interoperate to share registry data, and together they form a UDDI business registry. The registration centre is open to the public free of charge. All the entries in the UDDI Business registry are redundant on all operator (Operator) sites, but only the site where the entry is created can make changes to the entry.
IBM and Microsoft co-operate the 1th edition of the UDDI Services registry node, and both companies, as well as HP and SAP, are currently operating a beta testing site that supports most of the 2nd version of the UDDI specification. The four companies are planning to support version 2 production registries in 2002. Each company supports the SOAP APIs defined by the UDDI specification. Ensure consistency through business contracts. Several companies are free to provide additional services beyond what is required by the specification, such as a browser-based user interface (which all companies do).
Back to top of page
A glimpse into the UDDI specificationThe UDDI specification is made up of a number of documents. The API specification describes the SOAP APIs that allow you to perform discovery and publishing operations. The request/response semantics and error handling are also described. In addition, there is a lot of information about conventions and usages. The accompanying documentation includes the data structure specification (data Structure specification) and the API Schema, which define the message and data semantics.
The UDDI API belongs to the Inquiry or publishing category. Version 1th supports API operations, as shown in Listing 1.
Listing 1. Overview of the UDDI V1 APIInquiry Operations: publishing Operations:find Save find_business save_business find_service save_service find_binding save_binding find_tmodel save_tmodelget details Delete get_businessdetail delete_business get_servicedetail delete_service get_ Bindingdetail delete_binding get_tmodeldetail delete_tmodel get_registeredinfo get_ Registeredinfo Security get_authtoken Discard_authtoken
The query API has categorized itself into three query modes:
UDDI version 2.0UDDI defines four core data elements within the data model:
In addition to these core elements, version 2 adds support for establishing a relational model between enterprises.
The UDDI specification and UDDI Services registry provides a set of reference implementations that interoperate with each other, share registrations, and enable programming models that support design-time or runtime discovery services, depending on the client's needs. The instant integration value orientation of the IBM Web Service Initiative (Web Services Initiative), coupled with other important enabling technologies such as WSDL, allows agencies to perform dynamic discovery and binding of WEB services at runtime.
The continuous development of the UDDI specification has addressed issues in key areas such as data integrity, access control, identification, authentication, interoperability, improved data modeling capabilities, query and localization, and further increases the value of the UDDI registry.
find_xxx API to find incomplete name information.get_xxxThe API supports this feature.Although each top-level entity can be saved and deleted (exploits save_xxx and delete_xxx APIs), and is primarily automatic, it should be noted that the behavior of save operations in UDDI is often disruptive. For example, save the same service again, but the information is different, and the result is that the entity that previously represented the service was completely replaced.
authTokensrelated operations require that you pre-register with a UDDI services registry node to provide the credentials necessary to confirm the identity of the publisher. These credentials are used to obtain the use of the publish operation (leveraging save_xxx the API) authToken . If we assume authToken that there is no expiration, it can be reused for a short period of time during a tightly followed release operation. The regulations established by operators will determine authToken the content and longevity.
Back to top of page
What's new in UDDI version 2?UDDI Version 2 introduces a number of key features that can improve the quality and efficiency of the use of the version 1 specification for UDDI registries. The new features in version 2 are described in several sections below:
Back to top of page
Support ModelingThe main purpose of the update for support modeling is to help large organizations build models of their businesses and services more efficiently. Companies that involve large conglomerates of different kinds of risk to focus on a business and want to divide their web products by the geographic areas they serve, many want them to behave as independent but interconnected businesses on the web. In UDDI version 1, the only option for these cases is to keep the business independent but irrelevant. Version 2 allows you to define relationships between enterprises, such as parent-child relationships , Partners-partnerships , and equivalence relationships . In this way, you can build models for companies with subsidiaries, external business partners, or various internal departments, depending on the situation. A relationship can be formed between any two enterprises (as defined by their unique enterprise key). The TModel of the new business relationship type specification supports this capability, and there are new publishing APIs that allow you to define, delete, and request the state of the relationship, as shown in Listing 2.
The new query API called Find_relatedbusinesses allows you to relate to a given company's anonymous search. The other new publishing APIs in Listing 2 are related to the relationships that a particular publisher creates and owns, and these relationships are not accessible through anonymous queries. An enterprise relationship consists of a pair of identical relationship assertions, each of which links the two companies together and flags the specific relationships that are established. To form externally visible business relationships, each of the two companies involved must declare the same relationship assertion. Only those matching relationship assertions are find_relatedBusinesses() returned as query results.
The following example shows how relationships are formed and how relationships are discovered in the future. First, you get a release authorization token:
Listing 2. Get a AuthToken<envelope xmlns= "http://schemas.xmlsoap.org/soap/envelope/" > <body><get_authtoken generic= " 2.0 " xmlns=" urn:uddi-org:api_v2 " userid=" Businessa_userid "cred=" Businessa_password " /> < /body></envelope>
The return content is as follows:
Listing 3. Get AuthToken's response<envelope xmlns= "http://schemas.xmlsoap.org/soap/envelope/" > <body><authtoken generic= "2.0" operator= "Www.ibm.com/services/uddi" xmlns= "Urn:uddi-org:api_v2" > <authinfo>businessa_ Authtoken</authinfo></authtoken> </Body></Envelope>
Next, you build an enterprise assertion that links enterprise A to Enterprise B, where we don't use the typical UUID format, but instead businessKeys abbreviate them to Businesskeya and businesskeyb . For the sake of brevity, we no longer show SOAP envelopes.
<add_publisherassertions generic= "2.0" xmlns= "Urn:uddi-org:api_v2" > <authinfo>businessa_ authtoken</authinfo> <publisherAssertion> <fromKey> "Businesskeya" </fromKey> <toKey> "Businesskeyb" </toKey> <keyedreference keyvalue= "Parent-child" keyname= " Subsidiary " tmodelkey=" Uuid:c1acf26d-9672-4404-9d70-39b756e62ab4 "/> </publisherAssertion>< /add_publisherassertions>
Once the owner of Enterprise B has established a similar assertion, it can see a publicly visible corporate relationship in the registry. You can then use find_relatedBusinesses() the API to execute a simple query:
<find_relatedbusinesses generic= "2.0" xmlns= "Urn:uddi-org:api_v2" > <businessKey> "Businesskeya" </businessKey></find_relatedBusinesses>
Listing 3 shows the returned XML. A finer-grained query might include an identity that identifies the particular relationship that is being looked up keyedReference .
Another important feature added in version 2 to support the modeling needs of large enterprises is called Service Projection, which allows an enterprise to create a reference to a service owned by another enterprise. This can be useful in some cases, for example, for companies and generic services that provide the same services in two or more industries, such as overnight transportation, and many businesses want to link a generic service to the services they provide to encourage the use of the service.
The projected service reference is no more than a function. The creator of the service projection cannot change the real service being referenced, but in all other respects, the service is as if it were actually owned by the enterprise that created the projection. The service get_businessDetail() is get_serviceDetail() part of or returned by the API call. With ownership of the enterprise key associated with the service, you can differentiate the projection service from the real service. This key is always matched to the real enterprise that owns the service, not to the enterprise that created the service projection.
Back to top of page
Powerful classification featuresThree built-in taxonomies are available in version 1 for use in classification for businesses and services. They are NAICS industry taxonomy, UNSPC Project and service taxonomy, and iso-3166-2 geographic taxonomy. The UDDI Registry examines the use of these taxonomies internally, and attempts to save invalid code are rejected. The importance of a targeted taxonomy in UDDI cannot be overemphasized. Now that this is the most powerful way to find useful information of interest, the ability to create and control new taxonomies in the industry will continue to be high priority.
Version 2 new capabilities enable organizations to define new classifications of external checks that can be provided for public use in UDDI. These external taxonomy providers must support validate_values WEB services and enable UDDI business registries to access the service to support external checks and validation of the taxonomy values that clients want to associate with their entries in the registry. This is a controlled process. An externally validated taxonomy can be registered only if approved by a UDDI business registry operator.
This validation new feature allows the taxonomy provider to ensure that the taxonomy client using them can only save those valid taxonomy values in a flexible manner. When a client requests the use of a provider's taxonomy, the provider can also choose to have contextual validation in addition to verifying that the requester is legally using the taxonomy. More common, no-context scenarios also support the caching of taxonomy data in a UDDI business registry to reduce dependency on providers ' external taxonomy services.
Back to top of page
Enhanced queriesVersion 2 adds some powerful features to query on more complex requirements, based on previously available query capabilities. To enhance the existing find_xxx query API, several new filters (find qualifiers) are added, including,, orLikeKeys , orAllKeys combineCategoryBags , serviceSubset and andAllKeys . Among them, we are particularly interested in having combineCategoryBags , serviceSubset and orLikeKeys .
combineCategoryBagsQualifiers allow you to divide all the taxonomy data associated with an enterprise and all services included in the enterprise, including any service projections, into a collection, and then perform a search on that collection. This qualifier is useful because it reduces the steps to find an interested enterprise by simultaneously viewing the enterprise and the services it includes.
Similarly, serviceSubset filters allow you to use the taxonomy criteria to search for an enterprise and only perform such tests on the classifications that are associated with the services that comprise the enterprise. The classification that is associated with the enterprise itself is not included in this search method.
Finally, orLikeKeys qualifiers are particularly useful because they support complex pseudo-code queries. For example, you can find companies in the United States, Mexico, or Canada that provide refrigeration services or general transportation services. This allows you to search for businesses that are in categories at different feature levels, while allowing one query condition to reference many different taxonomies.
Back to top of page
InternationalizationEfforts have been made to improve the internationalization of UDDI, and some new features have now been added. Support for multiple names and codes has been added to BusinessEntity and Businessservice xml:lang . Although you must provide at least one name, you can also provide multiple names (each name uses a different language code).
Another internationalization feature in version 2 is the addition of a new taxonomy called postalAddress , which allows you to create tModel that describe localized postal addresses, and then associate them with addresses found in business entities.
Back to top of page
CopyAlthough UDDI clients cannot be seen directly, version 2 has made significant improvements to the replication operations between registry operators. UDDI version 1 supports only file-based replication patterns, with the increase in the number of registry nodes participating in the UDDI registry, with the increase in complexity in the square of N. Version 2 can accommodate a greater number of participating nodes, which replicate with each other. Replication can be done in a peer-based manner, with registry updates occurring on all other nodes on either node. Replication has now been further supported by the definition of a set of APIs that allow processing of changes and process management.
Back to top of page
NextThe next version of the UDDI specification is planned for 2002, with a focus on security, advanced data management, and further internationalization. Improve UDDI data integrity by enhancing access control, identity, and authentication to address security issues. This includes support for existing and emerging security technologies provided by organizations such as the and OASIS. Advanced data management capabilities will continue to enhance search capabilities to provide more accurate and hit-rate queries, better interpret query results, capture capabilities for richer and more meaningful descriptions of businesses and services, and better manage existing data. The improvements to internationalization will include supporting TNCs to describe their global operations in international business branches, as well as addressing the localization of UDDI data and services.
Back to top of page
ConclusionUDDI continues to evolve rapidly. UDDI version 2 was implemented by a number of UDDI Services registry operators in the public beta version of 2001. As version 3 of this specification will appear in 2002, the Registry will continue to add the functionality needed to do business on the Web, address security and the growing internationalization of issues, as well as some additional features to support the use of registries and interoperability.
http://www.ibm.com/developerworks/cn/webservices/ws-featuddi/
Start building with 50+ products and up to 12 months usage for Elastic Compute Service
1 on 1 presale consultation
24/7 Technical Support 6 Free Tickets per Quarter Faster Response
Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.
A comprehensive suite of global cloud computing services to power your business
Payment Methods We Support
