RE: [wsdm] [OMod] minutes of Oct 21th 2003 call

["ECKERT,ZULAH (HP-Cupertino,ex1)" <zulah_eckert@hp.com>]

Title: Message

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:Igor.Sedukhin@ca.com]
Sent: Tuesday, October 21, 2003 11:46 AM
To: wsdm@lists.oasis-open.org
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 .. (igor.sedukhin@ca.com)
-- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788