 | |||
|
|
||
| |||
| |||
| |||
|
||||||||||||||||||||
| |
|
Home > SOA News > Extending UDDI with robust Web services information |
| |
|
|
|
|
| SOA News: |
|
||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|
|||||||||||||||||||||||||||||||||||||||||
Market Analysis
Extending UDDI with robust Web services information
A WSDL port is mapped to a UDDI bindingTemplate. A tModelInstanceInfo container is used to refer to the tModels that were created for the portType and the binding, indicating that the port implements that portType (or interface) and that binding. UDDI Version 2 did not have categories on binding templates so there is no categoryBag on the bindingTemplate. WSDL services containing multiple ports are mapped to UDDI business services containing multiple binding templates. A categoryBag is created on each UDDI business service with the type category set to "service," the namespace and localname categories set to the namespace and localname of the WSDL service. Representing extended Web service attributes in UDDI This summary shows two major techniques that we can see used above to enhance the data stored natively about each Web service in UDDI. tModels as classes Generate tModel instances to represent objects associated with a given Web service. Represent attributes of those objects using categories on a categoryBag. One of the categories should have a reference to the tModelKey for the taxonomy that contains the type of the object. In effect, this is a way of creating entire new classes of objects that may be associated with a Web service. This is most appropriate when there are collections of information associated with a Web service that need to be represented. An example of this from the WSDL-UDDI mapping spec is the tModels that are generated for each WSDL portType and binding. Another example of this technique could be a new tModel for multiple attributes of performance information. It would be have a category that referred to another tModel with a taxonomy (in this case a simple list) of new types, such as "PerformanceInformation," "ReliabilityInformation," and "AvailabilityInformation." The keyValue could be one of those new types such as "PerformanceInformation." As with the WSDL- UDDI generated portTypes and bindings, there could be multiple categories on the new tModel, each representing an individual performance metric. These new generated tModels that act as "classes" can be referenced from a UDDI businessService's bindingTemplates using tModelKey references in the tModelInstanceDetails structure. They can also be referenced from categories on businessServices or on UDDI Version 3 bindingTemplates (using the ability to create new categories as attributes described below). Categories as attributes Create new built-in ("canonical") tModels for new attributes that you want to reflect on UDDI businessServices, bindingTemplates or "class tModels" described above. UDDI business services and UDDI V3 bindingTemplates can link to these tModels by adding a category to the categoryBag on the business service or bindingTemplate that references these new categories. An example of this technique from the mapping spec are the WSDL Entity Type and XML Namespace tModel that are placed as categories on the UDDI business services and the tModels to represent WSDL portTypes and bindings. Another example is that the performance of a Web service could be indicated with an additional tModel representing AverageResponseTime taxonomy, values of which could be stored in the categories on each WSDL-UDDI generated binding tModel. Summary UDDI is an excellent method of keeping track of Web services as an organization's volume of them grows. As UDDI usage increases, developers and users will want to have more information about each Web service available. Much of this information is stored elsewhere now. Recommendations such as the WSDL-UDDI mapping specification are a good way to enhance the information available in UDDI. The techniques that are used by the WSDL-UDDI spec can be applied to enhance the information available in UDDI even further. References [WSDL-UDDI] "Using WSDL in a UDDI Registry, Version 2.0" [UDDI-Data] "UDDI Data Structure Reference" About the Author Adam Blum is chief technology officer (CTO) of Systinet. Blum leads all technology strategy and positioning efforts. Blum spent five years with Microsoft Corporation, most recently as a manager in Microsoft s SQL Server product group. More recently, Blum served as the vice president of engineering at Talaris Corporation, a provider of a Web services-based platform for supplier integration of corporate services. At Talaris, Blum was responsible for all software development and QA. Blum also worked as Vice President of Engineering for CommerceOne where he managed development of all XML-related tools and platforms, including MarketSite, the world's first XML-based document integration server. Blum's Weblog, www.coarsegrained.com, covers Web services and XML approaches and tools. He can be contacted at adam.blum@systinet.com. You can also pose a question to Adam in our Ask the Experts section. Click here to visit his past UDDI answers and ask your question.
|
|
|
|
|||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||
|
|
About Us | Contact Us | For Advertisers | For Business Partners | Site Index | RSS |
|
|
||
|
|||||||
