-----Original
Message-----
From:
Morgenthal, JP [mailto:JP.Morgenthal@softwareagusa.com]
Sent: 26 January 2004 22:10
To:
uddi-spec@lists.oasis-open.org
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
From: CAHUZAC
Maud / FTR&D / US [mailto:maud.cahuzac@rd.francetelecom.com]
Sent: Friday, January 23, 2004 6:05
PM
To: blum@systinet.com;
uddi-spec@lists.oasis-open.org
Cc: GARG Shishir / FTR&D /
US
Subject: RE: [uddi-spec]
request for item on agenda at next FTF
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.