RE: [uddi-spec] request for item on agenda at next FTF

[blum@systinet.com]

Thanks for your prompt feedback.  I'd like to start out by saying that we really don't have a strong preference on the method used. Also, as far as the metrics tracked (and what categories there are) we rely on the management vendors and customers (such as yourselves) knowledge to supply such knowledge.  I also failed to mention in the document or elsewhere that Maud and Shishir were a huge driver in spurring us to try to do something here. 
 
It is far from too late to open a debate (though perhaps the real meat should occur in some form of working group to be initiated at the FTF?). Our only purpose was to start some form of TC or working group to author a standard.  We prepared a draft to set down some of our early thinking on
the subject and set out what seem to be the high level alternatives, although perhaps that step wasn't necessary.  Our hope is that customers such as yourselves and hopefully all web services management vendors sit down work together to create a technical note for storing WSM info in UDDI that everyone can work with (and the clean sheet of paper model may be even better to do that :-).  More comments below inline (although perhaps even those should wait for the Face to Face meeting to discuss if this topic gets on the agenda).   
 
Again, thanks for your continued urgency on this subject and your indepth knowledge of the requirements. I know it will create a better specification.
 
Regards,
 
- Adam 

>>--> TModel for QoS Information Pointing to External Resource   
We agree that this solution is very limited since the QoS document must be processed to retrieve QoS information and no UDDI query allows us to get this information.We have two questions for Adam: Are there only performance and reliability info in this XML document or can we find further details about the service QoS (such as all the metrics listed on the document as well as their units, life performance info, ...etc) ?Also, how this method affect the compliance with the WS-I Basic Profile which states that a service specification must be describe in a WSDL file ? <<
 This was meant to be a shorthand for pointing to some external resource:
a WSDL (yes, probably better) or other generic URL. .  We didn't spend much time defining this because we didn't think this would end up being the
recommendation.  

>>--> Multiple Categories for QoS Attributes
We think that this solution is interesting since each service implementation
is categorized with its own QoS parameters.   Of course, as long as you want
to categorize at the very maximum a UDDI entity, you will always have large CategoryBags. It is the same for all types of categorization: for instance, a business, which is established in 30 different countries, will be categorized with 30 different geographical taxonomy entries (and that is why taxonomy browsing mechanisms are really important in UDDI). <<
 Our thinking was that it may be best to put it on a generated tModel,
similar to the generated tModels for portTypes and bindings that occur in the Mapping WSDL to UDDI spec

>>Our concern here is how to provide users with metrics' unit in the CategoryBag? (does the ResponseTimeAverge is in second, millisecond, microsecond, ...?) <<
 We were definitely looking to management vendors to determine if  there is
a reasonable default for each metric or if other attributes (categories) identify the units.  The more that it seems impossible to properly "summarize" information in UDDI itself (via these categories) the more that it may drive usage of the "hook to detailed QoS service WSDL" that is one of the proposed categories on the bindingTemplate or generated tModel to retrieve detailed QoS information 

>> --> Extend the UDDI Data Structures