A: There are two primary kinds of UDDI information. The most important is the business registration, which describes the entire business entity or organization. The structure named "businessEntity" is the entire registration for a single organization (which can be a company, a web site, or any other kind of organization).

The other kind of information is for publishing specifications for building a particular type of service. For the most part, the tModel data structure is used to register the fact that a specification for a type of web service exists. This can be a specification for a way to use the web to do e-commerce, involving how you communicate with a service, what data you send to it, what data it returns when you use it. tModel registration can represent anything that can be described and that others will be interested in learning about so they can do the same thing the same way, or even just learn how to write the software that will make use of a service, for whatever purpose.

(The other UDDI data structures, called 'businessService' and 'bindingTemplate' are actually just details within the business registration. For instance, since a business may have a way to do selling, or several ways that they purchase things from their partners, the businessService data distinguishes one family of service from another. Within each businessService, the individual pieces — such as one way to send a shipping notice, or two ways to send a purchase orders – are represented in a data structure called a bindingTemplate.

A: These are programming entities primarily of interest to programmers.

These low level interim data structures are used to transmit the registered information to and from a UDDI registry.

"businessEntity" -- the entire registration for a single organization (which can be a company, a web site, or any other kind of organization). tModel data structure -- used to register the fact that a specification for a type of web service exists. This can be a specification for a way to use the web to do e-commerce, involving how you communicate with a service, what data you send to it, what data it returns when you use it. tModel registration can represent anything that can be described and that others will be interested in learning about so they can do the same thing the same way, or even just learn how to write the software that will make use of a service, for whatever purpose. 'businessService' and 'bindingTemplate' – are details within the business registration. For instance, since a business may have a way to do selling, or several ways that they purchase things from their partners, the businessService data distinguishes one family of service from another. Within each businessService, the individual pieces -- such as one way to send a shipping notice, or two ways to send a purchase orders – are represented in a data structure called a bindingTemplate.

A: There are two ways to register. After you apply (through Microsoft Passport) for permission to publish, you can use either a web site (UDDI Microsoft or other UDDI Operator site) and register using typical web site registration fill-in forms. Or you can communicate directly with the UDDI site using specially developed software either as part of products from software suppliers or marketplaces. (And, large corporations with many individual facets to be registered may have their own customized software.

A: Changing information happens by publishing replacement information. Again, you can use the UDDI Microsoft (or other UDDI Operator) web site to do this. Or, you can use packaged or customized software that communicates directly with the registry to update the information describing your business and available services.

A: Use the Search capability of this site, enlisting the standard and familiar business search taxonomies such as SIC codes or D-U-N-S® Number business identifiers.

A: While these UDDI mechanism are still being developed, large companies with many business units — or even marketplaces -- will be able to work out different mechanisms by contracting directly with one of the registries.

A: As UDDI evolves, several new members will be invited to join this UDDI steering group.

Q: Someone has registered information about my business without my knowledge. How do I resolve this?

A: As UDDI evolves, the individual registry operators can each manually "turn over the keys" through mechanisms that to be defined in the specifications.

Q: How do I reflect my organization's hierarchy – or define my company’s strategy for registration?

A: UDDI has published a technical white paper to explain how your company should use the facilities within the registration data to create hierarchies. More importantly, your organization should decide as a company your strategy for registration, the number of business units you want reflected in the registry, and how to explain your hierarchy to potential customers.

Additionally, you'll have to work closely with a registry operator to get the permissions required to publish a large amount of data about your business.

A: All of the information within the registry is public – but the specifications provide at least two ways to redirect people who find your business description to a site where you can establish your own degree of trust and security. A good rule of thumb with the public registry is not to publish information you don't want the whole world to use.

A: That's not an easy question. First, let's clarify: This question really means, "how do I know what standards or specifications my systems already use?" When first getting started with UDDI registration, you should inventory the services you are exposing to your partners on the web. If you're purchasing these solutions, the specifications will be dictated to you and you can work with your software vendor for the appropriate information.

If you've completely home-crafted all the specifications your software uses, you'll first have to inventory those, and then decide which to make completely public. For each of these, you'll want to publish a tModel before you register the fact you have any services -- and then use the references to these tModels within your business registration.

A: This question is easy: Publish them. Adding information to the UDDI registry isn't enough to make your specifications discoverable to others, however. Since the tModel really is just a structured way to identify a specification and a pointer to the actual URL where the specification is published, you'll have to decide if you want all of your tModels (specifications) available to the general public.

Each of the specifications you want to make public can be placed on another web site. Then when you register the specifications within the UDDI registry as a tModel, you simply point people seeking more information on a particular specification to the web address of your published specifications.

A: For the most part, they are self explanatory. You can also refer to the examples and/or read the specifications and other documentation that explains the registered data.

A: Each of the registry operators is responsible for ensuring that the customers who register information at a particular registry operator site has a way to deal with this. The process may be simple, such as simply remailing the password to the authorized users known email address, or it could be more complex. Each operator will decide.

Q: I'm building a new service (at my company), how do I know what tModels to use?

A: You really don't "use tModels". You register information about the services based on the specifications you used to build your services. In the case of purchased services, make sure your software vendors help you define this information. For those implementing an industry standard, you will want to consult with the standards organization involved. And if your own developers build a custom, one-of-a-kind service based on your own specifications, you’ll already know your own specifications, and easily can register these specifications, receiving back the appropriate tModel identifiers for your service descriptions.

A: If you are certain you registered them, you can use several of the provided search facilities to locate them. If you are truly the publisher -- the person who is logged-in to UDDI for Publishing -- you can ask UDDI to list all of the details about your registered information.

A: Always a good place to start is reviewing the specifications. Then, depending on your programming fortitude, you could build your own inquiries — requires an understanding of UDDI, SOAP, XML and HTTP — or you can use one of the software development kits (SDKs) that will be available from various UDDI registry operators (including Microsoft.

Basics of using the UDDI registry.