The UDDI Information Model
In my previous post I defined UDDI at a high level and provided a brief history of UDDI. I called out that UDDI standardizes two aspects of SOA Metadata. First it declares an information model using XML schema which is to be used as a standard way to represent SOA Metadata. Second, UDDI declares a collection of web services which are to be used as a standard way to access and manipulate the data represented by the information model.
In this post I want to investigate the UDDI information model. I will discuss the UDDI Web Services in my next post. As I go through the UDDI Information Model you will see that it is very course and general. This is because it was designed to be a one size fits all model. I also want to relate the data types in the UDDI information model back to the types I described in my post titled Metadata for an Enterprise SOA. This post was a more theoretical treatment of SOA metadata and it represents my opinion regarding the metadata that needs to be maintained for an Enterprise SOA to be effective. I avoided UDDI in this post because trying to understand the metadata needed for an enterprise SOA while at the same time trying to understand UDDI would have been confusing.
A common question with respect to UDDI is: “Where does UDDI play within a SOA Registry or a SOA System of Record?” Figure 1 below shows a SOA system of record. (A SOA System of Record is the combination of a SOA Registry and a SOA Repository. For more information, check out my post on the SOA Registry and Repository.) Remember that UDDI is a standard and as a standard it provides data portability and interoperability. Therefore, a good way to think about UDDI is to think of it as a layer on top of your SOA Metadata that provides data portability for your SOA metadata and interoperable access to your SOA Metadata.
Figure 1 – the SOA System of Record (Registry plus Repository)
Figure 1 also shows my SOA Metadata types which are listed in Figure 2 below for convenience. These are the types that I will relate to the UDDI information model at the end of this post.
1. Providers
2. Services
3. Taxonomy
4. Policies
5. Policy Associations
6. Configuration
7. Dependencies
8. Subscriptions
Figure 2 – My SOA Metadata types
The UDDI information model is really one large XML Schema file. You can check it out for yourself here. It contains a lot of type definitions (analogous to class definitions) and a lot of element declarations (analogous to variables which are declared to be instances of types). However, the core UDDI types listed in Figure 3 are all we need to investigate in order to understand the UDDI information model. All the other types are lower level types used to support these types or to define parameters needed by the UDDI Web Services.
1. tModel
2. businessEntity
3. businessService
4. bindingTemplate
5. tmodelInstanceInfo
Figure 3 – UDDI’s Core types
You may be wondering why the UDDI types are different from my SOA metadata types. The reason is that not everyone may agree with my SOA metadata design. I may have missed a data type that is important to some organization or I may have too much for another organization that has simpler needs. UDDI solves this problem by being very extensible. Just about any design can be mapped to the UDDI types making that design UDDI compliant. As we go through the UDDI information model you will see that it is very flexible and that it can be used to represent just about any design.
Overview of the tModel
tModel stands for technical model. It is the toughest type within UDDI to understand and it is at the heart of the UDDI Information model design. This is why I am describing it first.
From a functional perspective, the tModel provides three important features for UDDI. These three function areas are:
1. Defining Operational Parameters
2. Defining Value Sets for categorization
3. Defining find qualifiers for the UDDI Web Services
Let’s take a more detailed look at all of these uses of the tModel in the paragraphs below.
Defining Operational Parameters
The first use of the tModel is to hold operational parameters for a service. (In the UDDI specification this is sometimes referred to as defining the technical fingerprint of a service.) When services are consumed across process boundaries, machine boundaries or trust boundaries a lot of concrete operational parameters must be documented and understood by all consuming parties. The service’s address(s); the wire level transport (ex. TCP, Named Pipes, or HTTP); the protocols used (ex. WS-Security, WS-ReliableMessaging, and other WS-* standards), and service level agreements are examples of operational parameters. In the UDDI information model these operational parameters are documented via the tModel. It is important to note that the tModel itself does not contain all this information; rather, the tModel contains a URL that points to a document that contains these operational parameters. This document is usually stored in a SOA Repository (not to be confused with the SOA Registry – see Figure 1 for clarity). For example, WSDL files and policy files could be used to document the operational parameters I called out above. Many times it will take multiple tModels to fully describe the communication details of a particular service (policies plus WSDL). For example, multiple tModels could be used to create a service’s WSDL from reusable pieces in other tModels. These tModels could contain types and message contracts that are reusable across many services. Also there could be a tModel for each policy that is associated with the service. We will see how all this gets put together in order to fully describe the operational parameters for a service when we discuss bindingTemplates later in this post.
Defining Value Sets for categorization
The second use for the tModel within UDDI is to hold value sets that can be used as either a categorization system or as an identification system. This use of the tModel allows the other types within UDDI to be categorized or uniquely identified. The best way to visualize this usage of a tModel is to think of the tModel as holding a URL that points to an XML document that contains a list of valid name-value pairs. Categorization is important in a SOA Registry. Without a good categorization system (oftentimes referred to as a taxonomy) discovery is greatly compromised if not impossible.
Defining find qualifiers for the UDDI Web Services
The third general use for the tModel is to represent find qualifiers. Find qualifiers are values that modify how the find_xx suite of operations within the UDDI Web Service APIs works. For example, there is a tModel which causes the find_business operation to sort its results in the order in which they were published. This last use of the tModel does not pertain to the UDDI information model. This flavor of tModel pertains to the UDDI Web Services which I will cover in my next post.
As I discuss the remaining core types in the UDDI Information Model we will see examples of the first two tModel designs.
Architecturally, the tModel is designed to be the unit of reuse within UDDI. For example, if there is a policy that mandates secure communications for an organization then the tModel would hold that policy and the tModel could then be associated with all services that must conform to this policy. As another example of reuse within UDDI, oftentimes portions of a service’s WSDL file can be reused by other services – when this is the case these reusable portions can be described in their own tModel and linked together within UDDI to form a complete WSDL for some service. Message contracts and the types that make up message contracts are good examples of portions of a WSDL file that can be reused.
Figure 4 shows a diagram of the tModel. It contains elements that allow the tModel to be given a name and description. The overviewURL element is where the tModel points to documents which either represent operational parameters or a categorization system. Also notice that the tModel itself can be given a unique identity and categorized (the identifierBag and the categoryBag elements respectively).
Figure 4 – Diagram of the tModel type
businessEntity
The businessEntity type is the top level structure of the core UDDI types. It is used to describe a provider of services. Even though the name of this type may seem to imply that a business or an entire company should be described here you are free to use this type to describe any parent entity that is a provider of services. Companies, Departments, Applications, and even Servers in the datacenter are examples of entities that may be described with this structure. Figure 5 below shows a graphical depiction of the businessEntity type definition.
Figure 5 – Diagram of the businessEntity Type
As can be seen from the figure above, the businessEntity contains descriptive information about the provider of services. This includes the name of the provider, a free text description, contact information and categorization information.
The identifierBag can be used to uniquely identify a business entity. An example of an entry that may be found in the identifier bag would be a tax number. The categoryBag contains name-value pairs that categorize the business entity. Each name-value pair is associated with a tModelKey that references a tModel that can be used to validate the name-value pair. This is an example of the 2nd use of tModels that was described in the previous section. discoveryURLs point to external documentation about the business entity. UDDI also supports localization for name and description. Therefore, multiple entries for name and description can be entered - each entry representing a supported local. Finally, all of the UDDI core types have an element dedicated to digital signatures (dsig:Signature). This provides data integrity so that any malicious tampering of data can be detected.
businessService
The businessService type is designed to hold descriptive information about a logic service. This means that if you intend to deploy a specific service to multiple addresses then you would still only have one instance of a businessService in your UDDI Registry. Notice that there are no operational parameters in the businessService type. (The next type that I will describe is the bindingTemplate. It allows for the specification of operational parameters for each address a service is deployed to.) Similar to the businessEntity type, the businessService type also has a name, description, categoryBag, and Signature child elements. Figure 6 is a graphic showing both the businessEntity and the businessService type.
Figure 6 – The businessService type contained within the businessEntity type
Hierarchical Containment
At this point it is worth discussing how a businessService is related to a buisnessEntity in the UDDI information model. The mechanism by which these two types are related to each other is known as “hierarchical containment”. Figure 6 graphically depicts this relationship as it applies to the businessEntity and a businessService types.
If you are familiar with relational databases then this is a different way of visualizing a relationship between two types. Notice that businessServices are physically contained within their parent businessEntity. In other words there is no foreign key in the businessService that point to a businessEntity. While there is a businessEntity key in the businessService type (the businessKey attribute), its use here is not as a foreign key. Also notice that multiple businessServices may be contained within a single businessEntity; however, there has to be at least one businessService within each businessEntity. This is similar to how object oriented types are built up and related to each other to form object graphs. However a key difference is that in the UDDI information model each businessService must belong to exactly one businessEntity – it cannot be parentless and it cannot have multiple parents. This is in contrast with objects in Object Oriented architectures because often times a child instance may have multiple parents.
Hierarchical containment is used throughout the UDDI information model. Therefore understanding it is important to understanding the structure of UDDI.
bindingTemplate
A bindingTemplate and the types within it contain operational parameters for a specific service at a specific address. It is at this point in the UDDI information model that technical information about the service is captured. This is in contrast to the parent types (businessService and buisnessEntity) which contain non-technical contextual information about the service. The fact that a single instance of a bindingTemplate contains operational parameters for only a single service address is the key to understanding this data type and its relationship to its parent type the businessService. Remember that the businessService type describes a logical service. Many times an organization will have multiple instances of a logical service in production. For example, one instance of a service may support internal customers and another instance (listening on another address) may support external customers. In this situation there is clearly a need to run each service with different operational parameters since they support two different types of clients. For example, the internal service may be able to use a faster transport (TCP) while the service supporting external customers would have to use HTTP. Additionally the service supporting external customers would most likely require additional protocols such as WS-Security for authentication and privacy. Finally, two different service level agreements (policies) will need to be in place because the HTTP endpoint for external customers will not be able to guarantee the same response time as the TCP endpoint for internal customers.
For these reasons multiple bindingTemplates are needed by a single businessService. Within UDDI a bindingTemplate is hierarchically contained within a businessService. Figures 7 shows a diagram of the bindingTemplate and its relationship to the businessService type.
Figure 7 – The bindingTemplate type contained within the businessService type
tModelInstanceInfo
The tModelInstanceInfo type is not considered a core structure in most UDDI texts. Each tModelInstanceInfo element references exactly one tModel and is used to hold reference specific information about the tModel. Figures 8 shows a diagram of the tModelInstanceInfo type and how it is contained within the bindingTemplate type. Here we can see that multiple tModelInstanceInfo elements may be contained within a single bindingTemplate. It is important to note that the tModel is not contained within the tModelInstanceInfo type. The tModel is always referenced via its tModel key. The fact that tModels are always referenced as opposed to being contained is what allows the tModel to be reused by other services.
Figure 8 – The tModelInstanceInfo type contained within the bindingTemplate
Summary
The UDDI information model is an XML schema and it is designed for flexibility. Figure 9 below shows all the UDDI types and how they are related to each other. Just about any SOA metadata design can be represented with this model. Figure 10 shows how my SOA metadata types can be implemented with the UDDI information model.
The businessEntity and the businessService contain descriptive information about the business and each logical service within the business. The bindingTemplate, tModelIntanceInfo, and the tModel are used to specify operational parameters for each instance of a logical service.
The tModel is what gives the UDDI information model its flexibility. In addition to being used for the specification of operational parameters it is also used for the specification of identification systems (businessEntity and tModel), and categorization systems (all types).
Figure 9 - UDDI Core types and their relationship to each other
|
My SOA Types
|
UDDI types needed to implement my types
|
|
Providers
|
businessEntity
|
|
Services
|
businessService
|
|
Taxonomy
|
tModels to hold the value sets and the categoryBag element that is found in all the core UDDI types is used to categorize each instance of a type.
|
|
Policies
|
tModels
|
|
Policy Associates
|
tModels and categoryBags to hook them up to a taxonomy level for scoping purposes.
|
|
Configuration
|
bindingTemplate, tModelInstanceInfo and tModel
|
|
Dependencies
|
A clever use of categoryBags
|
|
Subscriptions
|
This is done using tModels and the UDDI Web Service APIs.
|