----- Original Message -----
Sent: Tuesday, January 27, 2004 11:09
AM
Subject: FW: [uddi-spec] request for item
on agenda at next FTF
All,
I would like to add some additional
thought to the work of Adam and Fred. I believe there is a more generic
category of "live" metadata that pertains to the registration, status, and
availability of Web Services. QoS is one such area, but so is
application configuration and dependency. For example, a composite
application that binds multiple Web Services into one should be able to be
described in the UDDI in such a way that if one Service is inoperable, the
status of the entire Composite application--through dependency chains--could
be deemed inoperable. By capturing a) a category of data that is marked
as volatile and b) a model for capturing the dependency of one tModel on
another. I believe we can accomplish the goals set forth by Adam and
Fred as well as enable a much greater capability for complete management of
composite software.
Regards,
JP
Dear all,
We are extremely interested in this topic and we are happy to
see Adam joining the TC. Here are our comments (for Adam and the TC) regarding
the different methods Adam proposed. To us, the best approach seems to be the
use of UDDI data structure extensions (see our comments below).
--> 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 ?
--> 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).
For this solution, don't you think it would be better to
create a QoS Taxonomy, which entries represent the different QoS metrics
(taxonomy entries can be hierarchical with sub-level metrics) and create only
one "Categorization" tModel to be used in the CategoryBag ?
Our concern here is how to provide users with metrics' unit in
the CategoryBag? (does the ResponseTimeAverge is in second, millisecond,
microsecond, ...?)
We guess that, with the progress made on the Semantic side, we
could have another Taxonomy for units, and "semantically" make a relationship
between the two taxonomies to provide Metrics and their units at the same
time. But, at the moment, there is no way to do this in UDDI.
--> Extend the UDDI Data Structures
From our perspective, this method seems to be the best approach. Also,
it would help drive adoption to UDDI V3.0.
Don't you
think that the data structure extensions could be standardized so that it
would avoid the issue of proprietary extensions? Moreover, we should determine
explicitly which of these standardized extensions are optional or
compulsory.
--> TModel for QoS Information Containing Multiple
Categories of QoS Attributes
With this solution, we
still have the issue of providing metrics' units within the CategoryBag of the
QoSInformation tModel even though this information can be easily found in the
WSDL file.
We know it is too late to open a debate on it and please bear
with us for the following comment :) We just have a little concern about the
use of WSDL in UDDI and probably you can help us to clarify our thoughts:
Usually, a tModel represents a reusable concept. In this solution, if the
QoSInformation tModel is categorized with the QoS metrics of a particular
service, it is tight to this service and this is not what a tModel is meant to
be. We thing that a tModel should be as generic as possible, representing a
specific concept/protocole/taxonomy (such as QoS information) but it should
not include any information that are bound to one service. What do you think?
Are we wrong or did we misunderstand the method?
Thank you !
Regards,
Maud
-----Original Message-----
From:
blum@systinet.com [mailto:blum@systinet.com]
Sent: Thursday, January 22, 2004 2:37 PM
To:
uddi-spec@lists.oasis-open.org
Subject: [uddi-spec]
request for item on agenda at next FTF
We would like to propose that a technical note be created for
how to store web services management information in UDDI. Specifically we
think that common quality of service metrics such as average performance,
reliability, throughput and availability should be easily available in
consistent locations in enterprise registries of web services. We believe that
this has great value for customers in providing predictable places to store
and search for such information to supplement the information about specific
physical implementations of web services, beyond what is natively available on
bindingTemplates. We also believe that having such standard ways of
accessing this information enhances the value of web services management
solutions for customers as there becomes a wider use of the QoS information
beyond just the management tool software itself. This includes the ability for
developers to use this information in search and browsing for appropriate web
service instances to use in a given situation.
We would like to involve as many web services management
vendors in drafting a recommendation on how and where to store such
information. We have posted a rough draft proposal for one possible method of
doing such storage (and several other alternatives are presented therein).
We are interested in discussing this at the February 10-12
Face to Face in San Francisco. It would be great if we could somehow get on
the agenda for this meeting. Thanks in advance for your
consideration.
Regards,
- Adam Blum, CTO, Systinet
- Fred
Carter, architect, Amberpoint
To unsubscribe from this mailing list (and be removed from the
roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/uddi-spec/members/leave_workgroup.php.