Understanding UDDI (4): Metadata System TMODEL
(This article was originally published by the IBM DeveloperWorks China website, its URL is http://www.ibm.com/developerWorks/cn/)
(This article is the TMODEL's use and structure of TMODEL, which is published in the developerWorks column. You need to browse the original text, please visit http://www.ibm.com/developerWorks/cn/)
TMODEL is one of the two top data entities (BusinessSentity and TModel) in the UDDI data model. TMODEL This term is a combination of multiple concepts. According to the description in the UDDI specification, TMODEL is used to represent a specification or a service type of service type. In the current UDDI implementation, there are four registered service types: "Classification System", "Identification System", "Abstract Interface Component" and "Specification" ). TMODEL is the carrier and performance form of these service types in UDDI registration data, is the metadata described in the web service. The TMODEL of a web service constitutes the technical fingerprint of this web service. Through the analysis of this technical fingerprint, we can easily understand how the web service is in line with those technical specifications, how to adopt, And information such as their classification and identification, etc.
What is TMODEL?
In order to achieve two or more softwares can be compatible with each other, that is, to achieve the goals of our expectations, they must share some design goals and general specifications. The registration information model supported by all UDDI sites is based on such sharing specifications.
Previously, in order to architecture a compatible software, the only way two companies can implement is to reach an agreement using the same specification, and then based on the protocol architecture software and test. However, if you use UDDI, companies need to organize software interface specifications and corresponding version information for designing the services they provide in some way, and publish them. In order to identify different public specifications (or private specification between specific collaborators), the information of the specification itself needs to be discovered. This information about the standard, that is, the traditional metadata structure, we call it TMODEL in UDDI.
For the developers of corporate business software, TMODEL provides a general method that as a general reference point, making compatible services can be simply identified. For companies that use this software, the advantage is to greatly shorten the process of identifying whether a particular service is compatible with your software. Finally, for software producers and standardization organizations, register a standardized information, then use this specification TMODEL to find the implementation of compatible web services, can help their customers really get the design specification that is widely used. Bring the benefits.
TMODEL structure
An important goal of UDDI is to describe a web service and make this description to provide sufficient semantic support when searching. Another goal is to provide a mechanism to make these descriptions are useful: When you don't understand a service, you can learn how to interact with this service through these descriptions. In order to do this, there must be a method to give sufficient information to the description, including the behavior performance of the service, what protocols are complied with, or whether the service meets what specifications or standards. One of the TMODEL structures is to provide a description ability that meets certain specifications, concepts or even a sharing design.
The TMODEL structure exists in the form of the metadata identified by the key (about data). In summary, the use of the TMODEL structure in the UDDI registration center is to provide an abstract reference system. Thus, the data category represented by the TMODEL structure is quite acomllent. In other words, a TMODEL registration information can define anything, but in the current version, we have applied two conventions, which use the TMODEL structure as the source of the compatibility and the namespace named space identified. . The TMODEL structure makeup information is very simple. They include a key, one name, an optional description, and a URL pointing to somewhere, may have a curious person to find the actual concept represented by the metadata in the TMODEL structure, that is, this URL may point to It is a text of a standard text or concept.
Two main purposes
In BusinessSentity Registration, you will find TMODEL references in two places. In this regard, TMODEL is very special. Although other data in BusinessSentity (such as BusinessService and BindingTemplate data) are existing as an instance of a unique parent BusinessEntity element, TMODEL is used in the form of a reference. This means you can find multiple references to a TMODEL instance in multiple business all, you can find multiple references to a TMODEL instance.
Define technical fingerprint
The main role of TMODEL is to exist as a mechanism that describes a technical specification. For example, an overview of a normative, switching format, a specification, or a specification of the exchange sequence rule. Such a specification can be discovered in the RosettaT Rnif 1.0 specification. Other examples can be found in some standards such as EBXML [1], ECO [2], and various electronic document exchange (EDI).
Software that communicates with other software through communication media always follows some pre-agreed specifications. In this case, the specified designer can use the TMODEL registration specification to achieve the purpose of establishing a unique technical identity in a UDDI registry.
Define abstract namespace references
Other places used in TMODEL are in the IdentifierBag and CategoryBAG structure defined in the organization identity and various classification information. In this context, the TMODEL reference indicates the association between the name / value of the key identifier, or the name / value pair and assignment of the name / value of the key identifier to the specific semantics The relationship between namespaces.
