Title: Message
Zulah,
Thank you for correcting the minutes. Those were important
points I forgot to capture.
About the metric/performance, do you want the group to
discuss it as an issue or was it just a note? Currently it says Metrics on
slide 17.
And immediately I have this use case. If, say, request
counters are used for security audits, then are those counters performance
information or security information or audit information or are they simply
metrics? Are all known "metrics" performance only? Can anyone guarantee
that?
If a metric is a number of autentication
failures on the resource, is that related to performance as
well?
-- Igor
Sedukhin .. ()
-- (631) 342-4325 .. 1 CA Plaza,
Islandia, NY 11788
From: ECKERT,ZULAH (HP-Cupertino,ex1)
[mailto:]
Sent: Monday, October 27, 2003 12:36
PM
To: Sedukhin, Igor S;
Subject:
RE: [wsdm] [OMod] minutes of Oct 21th 2003 call
For
issue #1 I have a few clarifications. We did agree to the capabilities listed in
the first bullet of slide 17, however the following discussion took
place:
* This
is the model for capabilities - not the mapping to an interface. As a model, it
represents the kinds of manageability capabilities that we expect Web services
to have. The mapping to an interface might be based on a different set of
categories (perhaps based on access control requirements). So, the information
model and the interface mapping are different things and will be based on
different requirements.
* The
term "atomic manageability capability" was not agreeable to the group because
the capabilities are not atomic.
I also
would like to call out my preference for the term "performance" over
"metric" as many of the things that will fall into this category (based on MTF
discussions) are counters from which metrics might be taken. What everything in
this group has in common is that it relates to the performance of the resource
under management.
Zulah
-----Original Message-----
From: Sedukhin, Igor S
[mailto:]
Sent: Tuesday, October 21, 2003 11:46
AM
To:
Subject: [wsdm] [OMod]
minutes of Oct 21th 2003 call
Roll: Igor, BrianC,
DanF, William, Zulah, Heather, Alexandro, Fred,
Andrea
Approval of minutes http://lists.oasis-open.org/archives/wsdm/200310/msg00075.html
approved
Agenda
ISSUE
1: identifying one atomic manageability capability which we
can model with props/ops/events/metadata, can we just stick to slide
17?
In
other words: do we lump all operations/props/events into one UML piece (class)
or do we split classes as indicated on slide 17.
[long discussion not
recorded]
DECISION: we will start defining a UML
model componentized according to categories (concerns, capabilities) expressed
on the slide 17 subbulets of the first bullet.
Igor: will send empty UML model with
those components
ISSUE 2:
manageability of a web service: inferred from manageable
endpoints or do we need to
define manageable service separately
The former means that an endpoint's
manageability information is sufficient to infer manageability of a service.
The manager can do it and may represent the manageable service which we may
define later, but not now. The later means that we define manageable service
as a separate concept and associate manageability capabilities and information
with it and not with an endpoint.
[long discussion on the culprits of the web
service concepts, not recorded]
DECISION: we will not define separate model
for a manageable service
ACTION: William to provide text on inferring
manageability of a service from manageable endpoints (generally, no specifics
of how)
William's concern about manageability
information to capture relationship of endpoints and services separately from
WSDL/UDDI, etc. was postponed until we get to discuss the actual manageability
model with concete properties, etc. William will propose and justify concrete
elements of the model at that point.
ISSUE
3: aggregation of manageability to the endpoint level is a
responsibility of the provider of manageability (need text for the concepts
section)
This is clear,
but needs an action item on someone to provide the
text.
BrianC's input: http://lists.oasis-open.org/archives/wsdm/200310/msg00080.html
Igor's answer: http://lists.oasis-open.org/archives/wsdm/200310/msg00081.html
ACTION: Fred to provide text for the
ISSUE 3.
ISSUE 4 (by BrianC): concepts of
versioning have to be applied to the MOWS Concepts diagram
Igor: yes, but may be as details of the concepts diagram: pick elements
that are necessary to express the versioning/revision concepts and draw a
diagram complimentary to the main diagram
ACTION: BrianC to provide a versioning concepts diagram
BrianC's input
http://lists.oasis-open.org/archives/wsdm/200310/msg00080.html
BrianC
presented the UML diagram on the page 3 of the http://lists.oasis-open.org/archives/wsdm/200310/doc00006.doc
- revisions are
infromation about the an element
- change
descriptions are information about transitions between
revisions
[Andrea's
comments?? sorry, didn't capture them]
BrianC:
question to the group: should revision concepts be part of the main diagram or
a detail diagram that compliments the main
diagram?
Andrea, DanF,
Igor: complimentary detail diagram
DanF&Igor
had a concern that version has to be expressed as well. For example a
versioned service "is a" service with version as an attribution. Revisions are
written against versioned elements (associated to). This applies to all other
elements that can be versioned.
BrianC
agreed.
ACTION: BrianC
to align the versioning/revision/change detail UML diagram with the MOWS
Concepts diagram and incorporate "versioned X is an X"
elements.
CALL
CLOSED
ISSUE
5: using http://lists.oasis-open.org/archives/wsdm/200310/msg00067.html UML
approach
ACTION: BrianC to attempt to express ManageableEndpointState
UML information model linked directly to the web service endpoint state
diagrams designed by the W3C Arch MTF.
Igor's simplified proposal: http://lists.oasis-open.org/archives/wsdm/200310/msg00082.html and
other possible choices http://lists.oasis-open.org/archives/wsdm/200310/msg00083.html
NOT DISCUSSED
ISSUE 6: There
is a need for another diagram to display the "locus of implementation"
concepts.
Essentially the diagram to depict
relationships between manageable endpoint in MOWS Concepts and manageability
endpoint in MUWS.
ACTION: Igor to provide "locus of implementation" concepts diagram
for MOWS.
See http://www.oasis-open.org/archives/wsdm/200310/msg00076.html
NOT DISCUSSED
ISSUE 7: another
diagram that shows relationships of MUWS and MOWS concepts (possibly
aggregation/composition of manageability capabilities).
NOT
DISCUSSED
-- Igor Sedukhin
.. ()
-- (631) 342-4325 .. 1 CA Plaza,
Islandia, NY 11788
