| Registries like UDDI and ebXML are essentially storehouses in which information about participant businesses is stored. And as with all information storage mechanisms, these registries have information models that model the types of information that can be created and stored. Although the registries store similar information for a business entity, the information models they follow are very different. The UDDI Information Model The UDDI registry specification declares that all UDDI-compliant registries must support the information models described in the following sections. businessEntity Information about a business is stored in the businessEntity element. The information set consists of different elements containing the unique identifier for the business, the name of the business, a description of the business, a list of categories and identifiers that describe the business, and a URL pointing to more information about the business. The businessEntity element contains the businessService, bindingTemplate, and tModel elements. Conceptually, you can think of businessEntity information as the yellow-page entry for the organization. This enables applications to search for businesses by industry, product, or geography. For example, the name element of the businessEntity structure will store the name of the business. Similarly, the description element will contain the description of the business. The businessEntity element contains within it the contact element, which in turn contains elements that describe the contact information of the business. For example, the personName element stores the name of a person who can be contacted, and the phone element stores the phone numbers for the business. Similarly, the email element is used to store the email address of the business. businessService Analogous to information contained in the green pages, this data structure contains information about the business services offered by the business entity and the technical descriptions of the Web services. The businessService structure represents a logical service classification; that is, it represents the Web services that are related to a business process or service category. Similar to the businessEntity element, the businessService element also has name and description elements, in which you can define the name of the service and its description. It also contains the bindingTemplate entity, which is described in the following section. bindingTemplate The bindingTemplate entity's data structure contains the technical Web service descriptions. These are the actual pieces of information that an application uses to connect and execute a Web service. The information includes the URL, binding key, and tModelInstance details. tModel The bindingTemplate entity provides the technical information needed to execute a Web service. However, simply knowing the URL is only one part of the process. The invoking application should also know other technical details, such as the format of the data supported by the Web service, protocols, security issues, the format of the response, and so on. Such technical specifications are represented by the tModels. The tModel element contains the pointer to technical specifications. Therefore, by referencing a specific tModel, a Web service guarantees that it is compatible with the technical specifications as laid out in the referenced tModel. publisherAssertion A single businessEntity is often not sufficient to represent all the business processes performed by large organizations. Therefore, such businesses publish many businessEntity structures. However, because they are part of the same business or enterprise, they are related. The publisherAssertion entity provides the capability with which one business can make visible in a UDDI registration its relationship with another business entity. The UDDI specification also provides two APIs the Publish API and the Inquiry API with which you can add information to these information models and query them. The ebXML Information Model The ebXML registry specification describes its information model as classes. Some of the important classes in the ebXML information model are described in the following list. -
RegistryObject This is an abstract base class that provides the metadata information for the registry objects. Almost all objects in the ebXML object model extend this object. -
Slot The Slot object provides the functionality by which attributes can be added to the instances of the RegistryObjects. For example, if a company wants to add a Warranty Disclaimer attribute to each of the submitted RegistryObject instances, it can do so by adding a Slot with the name Warranty_Disclaimer, and a value containing the disclaimer statement. -
Association These objects are used to define associations between objects stored in the information model. -
ExternalIdentifier Instances of this object provide additional identifier information to an instance of the RegistryObject class. Examples of additional identifier information include DUNS number, Social Security number, and so on. -
ExternalLink An ExternalLink object enables a company submitting some document to the registry to associate some external content to the submitted content. For example, if a company is submitting a DTD to the registry, it might want to associate the link to its home page with the DTD. It is important to remember that the content modeled by the ExternalLink object is not managed by the registry, and can therefore be changed, modified, or moved at any time. -
ClassificationScheme These instances provide the capability to classify or categorize the instances of the RegistryObject instances. Classification schemes can be defined to the registry either externally or internally. An example of the external classification is the North American Industry Classification System (NAICS). This classification provides a scheme by which businesses and services are classified by the industry to which they belong. -
ClassificationNode These instances are used to define tree structures under a ClassificationScheme, where each node in the tree is a ClassificationNode and the root is the ClassificationScheme. For example, different industries, such as HealthCare, Automotive, and so on, are ClassificationNodes under the Industry classification scheme. -
Classification These instances are used to classify the RegistryObject instances. -
RegistryPackage These instances are RegistryObject instances that group together the logically related RegistryObject instances. -
AuditableEvent These instances provide the mechanism to do audit trails for RegistryObject instances. -
User These instances provide information about the registered users of the registry. -
PostalAddress The PostalAddress class models the postal address information of an organization. -
EmailAddress Similar to the PostalAddress class, this class models the information structure of an email address. -
Organization These instances provide information about the organization that is submitting data to the registry. -
Service These instances provide information about the Web services. -
ServiceBinding A ServiceBinding instance provides the information on how to access a specific interface of a Service instance. Multiple ServiceBinding instances can exist for a Service. -
SpecificationLink A SpecificationLink provides the necessary link between a ServiceBinding and one of its technical specifications that describes how to use the service with that ServiceBinding. For example, a ServiceBinding might have a SpecificationLink instance that describes how to access the service using a WSDL document or a CORBA IDL document. |
Print 
E-Mail 
Add Note 
Add Bookmark
