----- Original Message -----
Sent: Friday, 6 February 2004 09:07
Subject: RE: [uddi-spec] request for item
on agenda at next FTF
We absolutely agree that the specific information
available should be defined by WSDM. The proposal is just intended to
identify the specific mechanism that such information will be reflected in
UDDI, which presumably there is value in the UDDI TC
identifying. But your point is well taken. I will be posting another
revision of the document today that makes that division of goals more
clear.
Wrt your questions:
- We think that having management information including
QoS metrics is valuable to potential developers that may consider using those
services and to administrators of those services. So yes, it is
intended for quality of service discovery. We also think there is value
to management software in having standard places to store that information,
but on an aggregated and not necessarily realtime basis. So yes, its to
"assist management software" but not at runtime (it will probably not be their
primary store for realtime and detailed
information).
- I see this fitting in well with registries with
access control policies, which would identify the management software as
a (or possibly the only) valid updator of this WSM information.
- The proposal is a method of attaching
WSM information to existing published services and binding templates for those
services. Those services and their physical implementation have
presumably gone through whatever validation and approval process is
appropriate. As you probably know we think an approval mechanism for
service publishing is a very good thing.
- We have assumed that the administrator
of the registry has determined who can publish WSM information attached to
services (via the mechanisms outlined in the paper). The
scenario you mention seems to be of a service publisher that
"self-assesses" their service or its implementation as having a certain
quality of service. We would consider this selfassessment to be a
service level agreement not QoS. And I agree it would be a bad
thing if every publisher of a service filled in their QoS information in
lieu of allowing the management software to do so. Perhaps, as
a best practice, ACLs should be used to restrict only certain parties
(such as the external management software) being able to update the QoS
information. Some of the approaches mentioned for storage of this
should make that easy enough to do.
My
interpretation of the posting is that this is not detailed enough on what
should be discoverable in UDDI from the Web services management information.
A better approach to solve the technical mapping between Web service
management and UDDI should include a detailed review of the specification in
development in the OASIS TC for Web services distributed management
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsdm
As an alternative, is it better to
recast this paper as end user quality of service discovery? From what I
read, the recommended metrics are being used by end users to select web
services, as opposed to management software. If that is the intent, I think
much more discussion of the context of the registry and who is asserting each
of the properties for the Web service is needed.
Answers to the following would help me understand the
proposal:
Is this proposal
intended to assist initial selection of a service from a user's perspective or
assist management software at runtime?
Is this proposal intended to apply to registries with particular access
control policies?
Is there any barrier
to publishing services in the registry such as validation of the service or
approval of the administrator of the registry?
Are there related services that can/should verify the
assertions made by the publisher who has labelled a service with a
certain metric?
Regards,
Andrew
Hately
IBM Austin
UDDI Development, Emerging Technologies
Lotus
Notes: Andrew Hately/Austin/IBM@IBMUS
Internet: hately@us.ibm.com
(512)
838-2866, t/l 678-2866
"Zdenek Svoboda"
<zdenek@systinet.com>
01/27/2004 08:48 AM
Please respond
to zdenek.svoboda |
|
To
| <uddi-spec@lists.oasis-open.org>
|
cc
|
|
Subject
| RE: [uddi-spec]
request for item on agenda at next
FTF |
|
To me there are following two use cases regarding
QoS metadata:
A) Searching for service by QoS metrics. Service QoS
metadata might be helpful in this scenario. As UDDI registry does not allow
for interval searches in keyedReference values, storing actual values (average
response time = 5.82 ms) does not add much value for searches. I would like to
see some well-defined categorization of major QoS metrics being defined in
this proposal (I'm not expert in WS management so I don't have any good
suggestion) so I know if the business service runs on somebody's laptop or on
corporate Sun E 10 000 machine.
B) Reading service QoS info. I think
that ideal way for accessing actual QoS data about business service is to
define some well-known service (QoSService) that provides complex QoS
information about the business service and reference the QoSService binding
template (deployment) from the business service binding template (either via
V3 compliant reference in categoryBag or tModelInstanceInfos). This approach
is very easy for management vendors who would simply implement the standard
the QoSService interface as layer on top of their QoS data stores. I can also
imagine some automated process that performs some aggregation on top of the
QoSService and regularly updates QoS categories described in ad A).
Regards
ZD
--
Zdenek Svoboda
Systinet Corp.
5 Cambridge Center,
Cambridge, MA 02142
Tel: (617) 768-4240
Fax: (617) 621-1168
From: John Colgrave
[mailto:colgrave@hursley.ibm.com]
Sent: Tuesday, January 27, 2004
5:02 AM
To: uddi-spec@lists.oasis-open.org
Subject: RE:
[uddi-spec] request for item on agenda at next FTF
I have always been
very wary of adding such “live” metadata to UDDI. Trying to describe
things like availability in UDDI can overlap with the support for
availability, workload management etc. in the servers hosting the
applications/services. Similarly, trying to represent service
compositions in UDDI overlaps with flow/process execution systems. Such
systems can allow for alternative services and compensating services so I
doubt it would be sufficient to deem every service inoperable that had a
(transitive) dependency on a particular service that was deemed
inoperable.
John Colgrave
IBM
-----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.