Maintaining the Core – Service Repository - Applied SOA Patterns on the Oracle Platform - page 322

</restriction>
</complexContent>
</complexType
So, the XML portion of this bag will be in tModel as presented in the following code:
</overviewDoc>
…
<categoryBag>
<keyedReference
tModelKey="uuid:
9AF82521-F6A9-1ba3-C094-2C7FE45CD859"
name="Another specification to web service or
other endpoint descriptor"
value="SomeWSDLSpec"/>
</categoryBag>
</tModel>
But wait, can you figure out what the structure is? Yes, you're right, it's a name-value pair.
What else could it be? There is no other way to define plural properties. By the way, the
schema for identifierBag is similar, but a bit simpler. Thus, the categoryBag ele-
ment is a collection of keyedReferences , where each of them is presented as a
tModel. Therefore, you can have a collection of technical specs in the form of tModels to
express different WS categories: messaging protocol, transport protocol, portType referen-
ces, MEP types, and so on. Actually, mapping between WSDL and UDDI V2-V3 is pretty
straightforward, and this fact raises a question: Why do we need a description for the de-
scription?
Well, individual services (for example, our milkman, postman, or doctor) could have a
good description of their individual capabilities, but we need a structure to put all of them
into our services' yellow topic. Again, we have pretty good mechanisms to build this
structure in the form of tModels, but we are (yet again) on our own in the quest of deliver-
ing it.
In the first chapter, we mentioned that our first attempt at establishing global service Dis-
coverability was not a real success, and now you can see why. Initially, UDDI was not
about web services, it was about business collaboration. tModels are just a way of describ-
ing entities and relations between them. The complete UDDI hierarchy consists of the fol-
lowing: