Real-world use of instanceParms in UDDI |
 |
By Gregg Bjork
18 Jun 2003 | SearchWebServices.com |
|
|
A member recently posed the following question to UDDI expert Gregg Bjork:
Where can I find more information about the format of the instanceParms field in the InstanceDetails structure?
Gregg replied:
Presumably, you are not looking for information on how the instanceParms element is nested inside the instanceDetails element, which is nested inside a tModelInstanceInfo, and so on. But rather how the instanceParms field might be used in the real world. Before explaining that, however, lets do look at where it sits in the overall UDDI structure.
UDDI is rooted at the businessEntity. Each business can register a number of businessServices. Each service can have multiple implementations and therefore multiple bindingTemplates. Associated with each binding should be a number of technical models (tModels) that help describe the technical aspects of a service's implementation. For instance, obeying UDDI Best Practices (version 1), there should be a tModel pointing at a service's WSDL document (and categorized as a "wsdlSpec"). You should add other tModels as necessary--for instance, to show that a service is authenticated or to state that a service is using SMTP as a transport.
The link between a bindingTemplate and a tModel is the tModelInstanceDetails element, which is simply an array of tModelInstanceInfo structures. Generally a tModelInstanceInfo simply contains the keyed reference to the real tModel. However, it does have two optional elements, one of which is the instanceDetails field. According to the UDDI specification, "This element can be used when tModel reference specific settings or other descriptive information are required to either describe a tModel specific component of a service description or support services that require additional technical data support (e.g. via settings or other handshake operations)" All well and good, but what does that mean? Very simply it means; if you have a tModel that describes some technical specification, but additional information may be necessary to the UDDI user, then put it here. For instance, one can imagine a tModel that references SSL itself. This tModel would be formal in your environment (it is not yet formal as far as UDDI is concerned). That is, there's a tModel out there that looks something like this.
tModelKey: b917c13d-f451-22ef-9a44-a4c562af23d8
name: SSL
description: "Transport independent encryption and authentication"
overviewDoc: http://wp.netscape.com/eng/ssl3/draft302.txt
Now it is entirely likely that if a service is SSL enabled that you would want to note as much in UDDI. But keep in mind that SSL is layered on top of other protocols. For instance, SSL can use a variety of encryption algorithms. In general you may not be interested in decorating your service representation with the fact that it's both SSL enabled and uses a certain subset of encryption algoriths, but then you may. And, if so, then the instanceDetails element is the place where this information should be specified. To illustrate one can imagine a UDDI structure that looks like this.
<businessEntity businessKey="...">
<name>Acme Corp.</name>
<businessServices>
<businessService serviceKey="..." businessKey= "...">
<name>Product Guide</name>
<bindingTemplates>
<bindingTemplate bindingKey="..." serviceKey="...">
<accessPoint URLType= "http">http://acme.com/productGuide</accessPoint>
<tModelInstanceDetails>
<tModelInstanceInfo tModelKey="uuid:b917c13d-f451-22ef-9a44-a4c562af23d8">
<instanceDetails>
<overviewDoc>
<overviewURL>http://csrc.nist.gov/publications/fips/fips46-3/fips46-3.pdf</overviewURL>
</overviewDoc>
<instanceParms>168 bit triple DES</instanceParms>
<overviewDoc>
<overviewURL>http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf</overviewURL>
</overviewDoc>
<instanceParms>128 bit AES</instanceParms>
</instanceDetails>
</tModelInstanceInfo>
</tModelInstanceDetails>
</bindingTemplate>
</bindingTemplates>
</businessService>
</businessServices>
</businessEntity>
This example is obviously fabricated, but it should give you an idea of the potential use of this optional element.
Click here to pose your own UDDI question.
|
|
|
|
