Key Features of UDDI4J Version 2
Look at the UDDI (Universal Description, Discovery and Integration) Project as a building block for e-commerce that's bigger and more important with every revision. As an open, comprehensive enabler, business processes can discover each other, dynamically define how they interact over the Internet, and transact with one another via their preferred applications. With this viewpoint, UDDI4J is a Java class library that enables applications to interact with any UDDI registry. This open-source library is endorsed by IBM, HP, and SAP, who are operators of the public UDDI Business Registry (UBR), and is freely available at www.uddi4j.org. HP offers its UDDI Version 2 public UBR at uddi.hp.com.
With the recent version 2 releases of UDDI and UDDI4J Version 2, several important new features are now available. UDDI Version 2 supports the ability to search trusted-partner services, provide localized service and business names, and share services between partners. UDDI4J provides full support of the UDDI Version 2 (V2) specification and includes support for multiple SOAP transports, configuration capabilities, and debug logging. With the introduction of these new features, applications can better locate and communicate with Web services.
Finding a Web service can be a tricky endeavor. They are executable objects accessible via XML that live anywhere on the Internet. Finding an appropriate set of services that match desired criteria is one purpose of a UDDI registry. The Web Services model has three main functions, called publish, find, and bind. UDDI provides two of them, namely publish and find. The publish function allows developers to place a service into a registry and identify the service. Find is the mechanism by which applications locate a services.
UDDI registry information is divided into five data structures. This data partitioning is meant to facilitate rapid location and use of registration semantics and be familiar to business users. Each structure contains fields that comprise a business or technical description purpose.
The five data structures are:
- BusinessEntity: Describes the publisher of services, typically an organization.
- BusinessService: Describes a service.
- BindingTemplate: Specifies service entry points and construction
- TModel: Specifies taxonomies (namespaces) or service types and is the basis for technical fingerprints.
- PublisherAssertion: Asserts a relationship between two parties, by one or both.
With the introduction of UDDI Version 2, both the UDDI specification and the UDDI4J classes include new features. Both sets of enhancements are described below, divided into specification and library features. The following new capabilities are part of the UDDI Version 2 specification:
- Creating partnerships through the Publisher Assertion.
- Service Projections are mechanisms to identify services shared between various organizations.
- Contact information is now structured and can be validated within a Taxonomy.
- Better support for multi-language requirements.
- Validation of categorization values.
The following features are new capabilities of the UDDI4J library:
- Logging features allow developers to view and store XML messages for events.
- Transport Independence allows multiple transport protocols to be employed.
In the UDDI registry, a company is described through a Business Entity object. The Business Entity object contains information about a company and its published services. Other information in the Business Entity identifies the company's business identifiers, e.g., Dunn & Bradstreet number, business categories, URLs, and other descriptive data to enable interaction with the company. Publisher Assertions offer useful mechanisms to link top-level Business Entities together, to identify various top-level businesses as part of the same company or partners.
Listing 1 contains a code fragment that shows how two companies assert a peer-to-peer, or partnership relationship between each other. In this example, Company A and Company B will assert a partnership. In order to complete a mutual assertion, the following code needs to be executed by Company A and Company B . "BkA" and "BkB" represents the key of Company A and Company B respectively, which is obtained during the creation of their Business Entity structures.
Listing 1: Code fragment for a mutual assertion.
String fromKey = "BkA";String toKey = "BkB"; KeyedReference keyedReference = new KeyedReference ("Partner Company","peer-peer");// Set the TmodelKey so that it refers to uddi-org:relationshipskeyedReference.setTModelKey(TModel.RELATIONSHIPS_TMODEL_KEY);PublisherAssertion publisherAssertion = new PublisherAssertion(fromKey,toKey,keyedReference);// token is AuthToken obtained using get_authToken() call earlier for the respective publisher// account ( Company A or Company B).DispositionReport dispositionReport=proxy.add_publisherAssertions(token.getAuthInfoString(), publisherAssertion);
In this code fragment, a KeyedReference object is constructed, which refers to the uddi-org:relationships Categorization and a valid value like "peer-peer", "parent-child", or "identity"in the uddi-org:relationships Categorization.
Next, a PublisherAssertion structure that has the Business Keys ("BkA" and BkB") of the businesses between which the relationship is being asserted (Company A and Company B) is constructed.
Finally, a call to
add_publisherAssertions() is made, which asserts the relationship between the fromKey ("BkA" or Company A) and the toKey ("BkB" or Company B).
This means that Company A has declared Company B as a partner but not vice-versa. Hence, the same program should be executed by swapping the keys and using Company B's "publisher" (login) account in UDDI.
This can be a useful feature to a client program, which may want to extend its trust with a known company to that company's partner. A client searching for a digital-printing service can search for HP and its partner, and be assured that the vendors are reliable and offer a service qualified by HP. This find can be done using the
find_relatedBusinesses() call. The trust can be further established by having the service classified (using taxonomies) as an "HP Certified Provider". Note, PublisherAssertion only establishes a relationship among Companies and is not an explicit mechanism to express trust for the services offered.
This feature allows sharing of services across Companies. Usually, companies having a relationship share services amongst themselves. This then allows clients to find related services that are developed by partnering companies. One benefit for the service publishers is that related services have a better chance of obtaining hits than standalone services. This mechanism can also enable outsourcing of services done by a Company (Business Entity).
This ability to share services across companies is referred to as service projection. This is accomplished simply by saving the Business Entity again with the shared service information. Now, the shared service would appear as a service listing of both the publishing Organizations.
Listing 2 contains the XML message fragment that achieves service projection.
Listing 2: Message fragment for service projection.
<businessEntity businessKey="uuid_1"> <businessServices> <!-- native business service --> <businessService serviceKey="uuid_a" businessKey="uuid_1"> ... </businessService> <!-- business service projected from business entity with uuid uuid_2 --> <businessService serviceKey="uuid_b" businessKey="uuid_2"> ... </businessService> <businessServices> <businessEntity>
In this example, a business with "uuid_2" is being shared between Company A and Company B. Company A has the businessKey "uuid_1" and Company B has businessKey "uuid_2".
The contact information used in storing a Business Entity structure contains an address structure, which in turn contains any number of AddressLine elements. In UDDI V2, this feature has been enhanced to hold a reference to a Taxonomy, or TModel data structure. The TModel structure is meant to represent taxonomies also ( namespace usage) apart from using them as service type . In this case, it offers a structure to the addressline by adorning it with a keyName-keyValue pair. This way, one can differentiate between various elements in the address (for example, whether it is a Street Name or City Name).
By using a checked Taxonomy, it can also be insured (with the help of validation services) that a publisher is using a known value in a given category, i.e., it can ensure a known ZIP code location refers to the city used.
Listing 3 contains a Message fragment that defines contact information using a taxonomy.
Listing 3: Message fragment for defining contact information via a Taxonomy.
<address useType="Development Office" tModelKey="uuid:A548"> // The TModel Key refers to a Postal Code Taxonomy.<addressLine keyName="Street" keyValue="1">Cunningham Road</addressLine><addressLine keyName="Street number" keyValue="2">29</addressLine><addressLine keyName="City " keyValue="3">Bangalore</addressLine>...<addressLine keyName="Country" keyValue="7">India</addressLine></address>
Page 1 of 2