wsdm message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: [OMod] suggested agenda for the next call (Heather leads the call)
- From: "Sedukhin, Igor S" <Igor.Sedukhin@ca.com>
- To: <wsdm@lists.oasis-open.org>
- Date: Mon, 20 Oct 2003 13:08:31 -0400
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
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.
ISSUE 7: another
diagram that shows relationships of MUWS and MOWS concepts (possibly
aggregation/composition of manageability
capabilities).
-- Igor
Sedukhin .. (igor.sedukhin@ca.com)
-- (631) 342-4325 .. 1 CA Plaza,
Islandia, NY 11788
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 .. (igor.sedukhin@ca.com)
-- (631) 342-4325 .. 1 CA Plaza,
Islandia, NY 11788
Agenda of the call today:
A. Administrativa
Roll
B. Action items
ACTION: Igor to send out an example representation of one
atomic capability model before the next call.
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 .. (igor.sedukhin@ca.com)
-- (631) 342-4325 .. 1 CA Plaza,
Islandia, NY 11788
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
..
(igor.sedukhin@ca.com)
-- (631) 342-4325 .. 1 CA Plaza,
Islandia, NY 11788
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]