| JavaBeat |
|
| SCDJWS Home | Objectives | Tutorials | Forums |
|
The UDDI Data StructuresData in a UDDI registry can be conceptually divided into four categories, each of which represents a top-level entity in UDDI. Each of the main UDDI structures
is assigned a unique key, in the format of a GUID.
The bussinessEntity 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.
<element name="businessEntity" type="uddi:businessEntity"/> The structure of the UDDI "businessEntity" entry is nested at three levels.
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 structureThe 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.
<element name="businessService" type="uddi:businessService" /> 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 structureTechnical 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.
<element name="bindingTemplate" type="uddi:bindingTemplate" /> 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 structureBeing 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.
To get things started, the UDDI Operator Sites have registered a number of
useful tModels, including NAICS (an industry code taxonomy), UNSPC (a product
and service category code taxonomy), and ISO 3166 (a geographical region code
taxonomy).
<element name="tModel" type="uddi:tModel" /> The publisherAssertion structureMany 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 keyName keyValue 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.
<element name="publisherAssertion" type="uddi:publisherAssertion" />
The WS-I Basic Profile 1.0 Requirements - Service Publication and DiscoveryREGDATA of type uddi:bindingTemplate representing a conformant INSTANCE MUST contain the uddi:accessPoint element.
CORRECT: REGDATA of type uddi:tModel representing a conformant Web service type MUST use WSDL as the description language. REGDATA of type uddi:tModel representing a conformant Web service type MUST be categorized using the uddi:types taxonomy and a categorization of "wsdlSpec". The wsdl:binding that is referenced by REGDATA of type uddi:tModel MUST itself conform to the Profile. |
|
|
|
|
|
|
| JavaBeat 2006, India | javabeat home | About Us | partners directory | Advertise with us | |
|
|
|
