Are You Recruiter/Hiring Manager

*Filter candidates using TestYourCandidate.com and save 80% time ( saving time for recruiters and interviewers)
*More than 50% candidates can be filtered on Candidate Screening online tests
*Inbuilt exams are available in library, created and tested by experts Try Today...

Describe the use of UDDI data structures. Consider the requirements imposed on UDDI by the
WS-I Basic Profile 1.0a.

UDDI supports the following core data structures:

Business Entity

Business Service

Binding Template

tModel

Publisher Assertion

This division by information type provides simple partitions to assist in the rapid location and understanding of the
different information that makes up a registration.

The businessEntity structure

The businessEntity structure represents all known information
about a business or entity that publishes descriptive information about
the entity as well as the services that it offers. From an XML standpoint, the businessEntity is the top-level
data structure that accommodates holding descriptive information about a business or entity. Service descriptions and technical
information are expressed within a businessEntity by a containment relationship.

The businessServices structure provides a way for describing information about families of services.
This simple collection accessor contains zero or more businessService structures and has no other
associated structures.

The identifierBag element allows businessEntity or tModel structures
to include information about common forms of identification such as D-U-N-S numbers, tax identifiers, etc. This data can be used
to signify the identity of the businessEntity, or can be used to signify the identity of the publishing party.
Including data of this sort is optional, but when used greatly enhances the search behaviors exposed via the
find_xx messages defined in the UDDI Version 2.0 API Specification.

The categoryBag element allows businessEntity, businessService
and tModel structures to be categorized according to any of several available taxonomy based classification
schemes. Operator Sites automatically provide validated categorization support for three taxonomies that cover industry
codes (via NAICS), product and service classifications (via UNSPC) and geography (via ISO 3166). Including data of this
sort is optional, but when used greatly enhances the search behaviors exposed by the find_xx messages
defined in the UDDI Version 2.0 API Specification.

The businessService structure

The businessService structures each represent a logical service classification. The name of the element
includes the term "business" in an attempt to describe the purpose of this level in the service description hierarchy.
Each businessService structure is the logical child of a single
businessEntity structure. The
identity of the containing (parent) businessEntity is determined by examining the embedded
businessKey value. If no businessKey value is present, the
businessKey must be obtainable by searching for a businessKey value in any parent
structure containing the businessService. Each businessService element contains
descriptive information in business terms outlining the type of technical services found within each
businessService element.

In some cases, businesses would like to share or reuse services, e.g. when a large enterprise publishes separate
businessEntity structures. This can be established by using the businessService structure
as a projection to an already published businessService.

Any businessService projected in this way is not managed as a part of the referencing
businessEntity, but centrally as a part of the referenced businessEntity. This means
that changes of the businessService by the referenced businessEntity are automatically
valid for the service projections done by referencing businessEntity structures.

In order to specify both referenced and referencing businessEntity structures correctly, service
projections can only be published by a save_business message with the referencing
businessKey present in the businessEntity structure and both the
referenced businessKey and the referenced businessService present in the
businessService structure.

The bindingTemplates structure is a container for zero or more bindingTemplate structures.
This structure holds the technical service description information related to a given business service family.

The categoryBag is an optional element. This is an optional list of name-value pairs that are used to
tag a businessService with specific taxonomy information (e.g. industry, product or geographic codes).
These can be used during search via find_service.

The bindingTemplate structure

Technical descriptions of Web services are accommodated via individual contained instances of bindingTemplate
structures. These structures provide support for determining a technical entry point or optionally support remotely hosted
services, as well as a lightweight facility for describing unique technical characteristics of a given implementation.
Support for technology and application specific parameters and settings files are also supported.

Since UDDI’s main purpose is to enable description and discovery of Web Service information, it is the
bindingTemplate that provides the most interesting technical data.

Each bindingTemplate structure has a single logical businessService parent, which
in turn has a single logical businessEntity parent.

The accessPoint element is an attribute-qualified pointer to a service entry point. The notion of service
at the metadata level seen here is fairly abstract and many types of entry points are accommodated.
A single attribute is provided (named URLType). The purpose of the URLType attribute
is to facilitate searching for entry points associated with a particular type of entry point. An example might be a
purchase order service that provides three entry points, one for HTTP, one for SMTP, and one for FAX
ordering. In this example, we’d find a businessService element that contains three
bindingTemplate entries, each with identical data with the exception of the
accessPoint value and URLType value.

The tModelInstanceDetails structure is a simple accessor container for one or more
tModelInstanceInfo structures. When taken as a group, the data that is presented in a
tModelInstanceDetails structure forms a technically descriptive fingerprint by virtue of the
unordered list of tModelKey references contained within this structure. What this means in
English is that when someone registers a bindingTemplate (within a businessEntity structure),
it will contain one or more references to specific and identifiable specifications that are implied by the
tModelKey values provided with the registration. During an inquiry for a service, an interested party could
use this information to look for a specific bindingTemplate that contains a specific
tModel reference, or even a set of tModel references. By registering a specific
fingerprint in this manner, a software developer can readily signify that they are compatible with the specifications
implied in the tModelKey elements exposed in this manner.

The tModel structure

Being able to describe a Web service and then make the description meaningful enough to be useful during searches is an
important UDDI goal. Another goal is to provide a facility to make these descriptions useful enough to learn about how to
interact with a service that you don’t know much about. In order to do this, there needs to be a way to mark a description
with information that designates how it behaves, what conventions it follows, or what specifications or standards the service is
compliant with. Providing the ability to describe compliance with a specification, concept, or even a shared design is one of the
roles that the tModel structure fills.

The tModel structure takes the form of keyed metadata (data about data). In a general sense, the purpose
of a tModel within the UDDI registry is to provide a reference system based on abstraction. Thus, the
kind of data that a tModel represents is pretty nebulous. In other words, a tModel registration
can define just about anything, but in the current revision, two conventions have been applied for using
tModels: as sources for determining compatibility and as keyed namespace references.

The information that makes up a tModel is quite simple. There’s a key, a name, an optional description,
and then a URL that points somewhere – presumably somewhere where the curious can go to find out more about the actual concept
represented by the metadata in the tModel itself.

There are two places within a businessEntity registration that you'll find references to
tModels. In this regard, tModels are special. Whereas the other data within
the businessEntity (e.g. businessService and bindingTemplate data)
exists uniquely with one uniquely keyed instance as a member of one unique parent businessEntity,
tModels are used as references. This means that you'll find references to specific
tModel instances in many businessEntity structures.

Defining the technical fingerprint.

The primary role that a tModel plays is to represent a technical specification. An example might be
a specification that outlines wire protocols, interchange formats and interchange sequencing rules. Examples
can be seen in the RosettaNet Partner Interface Processes specification, the Open Applications Group Integration Specification
and various Electronic Document Interchange (EDI) efforts.

Software that communicates with other software across some communication medium invariably adheres to some pre-agreed
specifications. In situations where this is true, the designers of the specifications can establish a unique technical
identity within a UDDI registry by registering information about the specification in a tModel.

Once registered in this way, other parties can express the availability of Web services that are compliant with a
specification by simply including a reference to the tModel identifier (called a
tModelKey) in
their technical service descriptions bindingTemplate data.

This approach facilitates searching for registered Web services that are compatible with a particular specification.
Once you know the proper tModelKey value, you can find out whether a particular business or entity
has registered a Web service that references that tModel key. In this way, the
tModelKey becomes a technical fingerprint that is unique to a given specification.

Defining an abstract namespace reference.

The other place where tModel references are used is within the identifierBag,
categoryBag, address and publisherAssertion structures that
are used to define organizational identity and various classifications. Used in this context, the
tModel reference represents a relationship between the keyed name-value pairs to the
super-name, or namespace within which the name-value pairs are meaningful.

An example of this can be seen in the way a business or entity can express the fact that their US tax code
identifier (which they are sure they are known by to their partners and customers) is a particular value. To do this, let's
assume that we find a tModel that is named “US Tax Codes”, with a description “United States business tax
code numbers as defined by the United States Internal Revenue Service”. In this regard, the tModel still
represents a specific concept – but instead of being a technical specification, it represents a unique area within which tax
code ID’s have a particular meaning.

Once this meaning is established, a business can use the tModelKey for the tax code
tModel as a unique reference that qualifies the remainder of the data that makes up
an entry in the identifierBag data.

Many businesses, like large enterprises or marketplaces, are not effectively represented by a single businessEntity,
since their description and discovery are likely to be diverse. As a consequence, several businessEntity
structures can be published,
representing individual subsidiaries of a large enterprise or individual participants of a marketplace. Nevertheless, they still
represent a more or less coupled community and would like to make some of their relationships visible in their UDDI registrations.
Therefore, two related businesses use the xx_publisherAssertion messages, publishing assertions of
business relationships.

In order to eliminate the possibility that one publisher claims a relationship between both businesses that is in fact not
reciprocally recognized, both publishers have to agree that the relationship is valid by publishing their own
publisherAssertion. Therefore, both publishers have to publish exactly the same information. When
this happens, the relationship becomes visible.

In the case that a publisher is responsible for both businesses, the relationship automatically becomes visible after publishing
just one of both assertions that make up the relationship.

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 keyNamekeyValue pair within a
tModel, uniquely referenced by a tModelKey. All three parts of the
keyedReference – the tModelKey, the keyName, and the
keyValue – are mandatory in this context. Empty (zero length)
keyName and keyValue elements are permitted.