[OMod] suggested agenda for the next call (Heather leads the call)

Title: [OMod] call this week moved to Fri, Oct 17th, 3-4pm EST


I suggest that the 
discussion takes place and some conclusions are made on the following 
issues.

 

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.

 

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.

 

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.

 

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

 

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.

 

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

 

ISSUE 7: another 
diagram that shows relationships of MUWS and MOWS concepts (possibly 
aggregation/composition of manageability 
capabilities).

-- Igor 
Sedukhin .. () 
-- (631) 342-4325 .. 1 CA Plaza, 
Islandia, NY 11788 

 

From: Sedukhin, Igor S 
Sent: Friday, 
October 17, 2003 6:01 PM
To: 

Subject: [wsdm] [OMod] minutes of Fri, Oct 
17th, 3-4pm EST call

Roll: BrianC, DanF, Heather, FredC, 
William

minutes are approved

 

BrianC: why endpoints and not web 
services

Igor: we discussed this at the requirements time. It is 
a manager's responsibility to infer manageability of a web service from 
manageability of endpoints that aggregate into a service. We want to provide 
sufficient information to make it possible, but we want to ask to provide only 
information from endpoints in the first cut of a spec.

 

Moved on to discussing the UML 
sketches.

Igor: explained the diagrams, their intention 
and tie into the MOWS Concepts diagram.

 

William: why the capabilities model was split that way? 
did we not agree on another way of splitting it?

Igor: refer to F2F PPT by Heather, slides 20 and 17. 
That is why.

Heather: the group has come up with slide 17 because 
our most agreeable set of "topics" was properties, operations, events and 
metadata. It did not appear that it is reasonable to lump all of those in one 
place, and so group has decided to define them in the information groups of 
identification, state, etc . (see slide 17).

Igor: in the UML model we simply follow that and define 
manageability capabilities in terms of props, ops, events & metadata 
specifically for an endpoint. We go about grouping information so that it is 
sufficient to express semantics of ONE named manageability 
capability.

William: will take it back to HP for 
discussions.

ISSUE: identifying one atomic manageability capability 
which we can model with props/ops/events/metadata, can we just stick to slide 
17?

 

William: what about manageability of a web 
service.

Igor: [same as above]. We need someone to provide the 
text on that.

ACTION: BrianC to provide "Text in the overview of the MOWS spec 
must elaborate on the manageability at the service level. Essentially "how to 
use manageability of endpoints to infer (aggregate) manageability of a 
service"."

William: will take it back to HP for discussions

ISSUE: 
manageability of a web service: inferred from manageable endpoints or we 
need to define manageable service separately

 

William: what about a load balanced server farm situation. Someone needs 
to aggregate information to represent manageable endpoint.

Igor: 
yes, this issue has been raised by GeoffB on our previous call. Our spec must 
say that provider of manageability of an endpoint must be able to aggregate that 
information consistently with the implementation and deployment models used 
behind the endpoint. We need to define the boundary after which the resource is 
not a web service anymore. The most reasonable is to use WSDL concepts of Web 
services and say that anything behind an endpoint is an implementation and 
disappears from the web services space that we need to define manageability for. 
We need to define the manageability of the basis elements from which web 
services concepts are built and that appears to be 
endpoints.

ISSUE: 
aggregation of manageability to the endpoint level is a responsibility of the 
provider of manageability (need text for the concepts 
section)

 

Igor: 
discussed if the UML sketches provided are sufficiently expressive to cover 
definition of manageability capabilities that we need. Approach is that every 
one manageability capability is named and then props/events/ops are modeled in a 
UML class with associated structured information (data types, event 
information) represented in UML classes too.

BrianC: why the ManageableEndpointState UML has enumerations of states 
and transitions instead of state transition diagram itself?

Igor: 
because we need to express information model in which we need to represent 
structured information as "data types" of some sorts. For example 
RequestProcessingTransitionSettings information needs to include transition 
information as a property (or a subelement). There was no better way to 
represent the information model. The state transition diagram is necessary, but 
as supplementary to the information model in the spec 
document.

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.

 

ISSUE 
(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

 

ISSUE: 
another diagram that shows relationships of MUWS and MOWS concepts (possibly 
aggregation/composition of manageability capabilities).

Not 
resolved at this time.

 

ISSUE: 
There is a need for another diagram to display the "locus of implementation" 
concepts.

Igor: 
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.

 

Igor: 
inquired if there are any objections to using the approach in UML that was 
presented so far to express manageability capabilities to endpoints taking into 
account the recorded issues and action items.

no 
objections so far

 

Administrativa: next call

ACTION: Heather to host the [OMod] call next week and send the phone 
number.

-- Igor 
Sedukhin .. () 
-- (631) 342-4325 .. 1 CA Plaza, 
Islandia, NY 11788 

 

From: Sedukhin, Igor S 
Sent: Friday, 
October 17, 2003 12:09 PM
To: 

Subject: RE: [wsdm] [OMod] call this week 
moved to Fri, Oct 17th, 3-4pm EST

Agenda of the call today:

 

A. Administrativa

Roll

Approve minutes (http://lists.oasis-open.org/archives/wsdm/200310/msg00016.html)

 

B. Action items

 

ACTION: Igor to send out an example representation of one 
atomic capability model before the next call.

See http://lists.oasis-open.org/archives/wsdm/200310/msg00067.html

 

C. Discuss the MOWS UML 
sketches.

 

D. Find volunteers for 
the following (coming from the discussion about the MOWS Concepts diagram.) 

 

1. Text in the 
overview of the MOWS spec must elaborate on the manageability at the service 
level. Essentially "how to use manageabilty of endpoints to infer (aggregate) 
manageability of a service".

2. The diagram will show a shade on the nexus points of MUWS and MOWS 
(manageable resource and manageable endpoint respectively). Only nexus points 
will be singled out on this diagram. There will be abother diagram that shows 
relationships of MUWS and MOWS concepts (possibly aggregation/composition of 
manageability capabilities).

3. There is a need for another diagram to display 
the "locus of implementation" 
concepts.

E. 
Next call: I cannot lead the call next week need someone to lead 
it

-- Igor 
Sedukhin .. () 
-- (631) 342-4325 .. 1 CA Plaza, 
Islandia, NY 11788 

 

From: Sedukhin, Igor S 
Sent: Monday, 
October 13, 2003 1:40 PM
To: 

Subject: [wsdm] [OMod] call this week moved 
to Fri, Oct 17th, 3-4pm EST

As discussed and assuming that all 
interested Omod participants have replied, the Omod call moved to Friday Oct 
17th 3-4pm EST (12-1pm PST). Only one occurrence of the call is moved, all 
future calls will be on Tuesdays as scheduled. TERE WILL NOT BE A CALL THIS 
TUESDAY (tomorrow), unless someone else wants to host it.

Reservationless-Plus Toll 
Free Dial-In Number: (888) 827-2241
Reservationless-Plus International Dial-In Number: (706) 679-8701
Conference Code: 
6313424325 

-- Igor Sedukhin 
.. 
() 
-- (631) 342-4325 .. 1 CA Plaza, 
Islandia, NY 11788