OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsdm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [wsdm] MOWS Document Comments


Replies on replies, moved up here.

2. Headings - I like your suggestion of "Manageability Representation
Topics" as the heading for 2.1, and would prefer "Model" for 2.1.3,
especially since the headings are "Mod .x" :-).

4. About [Overall 2.], Mark says "the model we will come up with will be
pure UML that includes both data (properties), behaviour (operations)
and events. This can be further rendered into a CIM model and then as
CIM-XML, however I missing something about CIM models here?"
I think that you may be missing something :-). CIM is about semantics
and can be render in UML or MOF. The original spec was written in the
mid 90's and is being updated to take advantage of the newest UML spec,
stereotypes, etc.  In the mean time, CIM includes everything that you
list above - properties, operations and events/indications - and its
semantics (even if the MOF language is ignored) can/should be reused.
OTOH, rendering UML in MOF removes a lot of ambiguities that get missed
with UML/pictures.  I am not necessarily advocating WBEM - which is the
specific CIM-XML encoding, but I see NO need to reinvent semantics and
see nothing that is contrary to what CIM has defined.  This work would
easily build on CIM's concepts.  CIM is an evolution, not a static
definition.

5. Met 1 - The discussion on the call last week clarified this, for me.
However, the current wording in the document needs to be stronger
(IMHO).  Could I recommend using some of your words - "[Met. 1.] The
manageability representation MUST support the concept of metrics, i.e.
the ability to define and track metrics [22]"

6. Mod 6 - Your wording works for me "The manageability representation
MUST NOT be specific to a particular
data or interface representation."

7. Chng 6, "The manageability representation SHOULD enable grouping of
changes.  The notion of /change package/ allows for a collection of
changes to be described as "all or nothing". 
Mark says "this is a notification not an action".  
Given this comment, I think that it is incorrect to state "all or
nothing".  I would reword the requirement as "The manageability
representation SHOULD enable grouping of changes.  The notion of /change
package/ allows for a collection of changes to be described as a group,
and notifications reported on the group as a whole."

Andrea

-----Original Message-----
From: Potts, Mark [mailto:mark.potts@hp.com] 
Sent: Friday, September 26, 2003 3:41 PM
To: Andrea Westerinen; Igor.Sedukhin@ca.com
Cc: wsdm@lists.oasis-open.org
Subject: RE: [wsdm] MOWS Document Comments


Andrea

Responses below... Lets discuss Monday if we can
 
> Feedback on the Management Of Web Services:
> 
> 1. Since every requirement references "Manageability
> Representation", it is really important to define it clearly. 
>  In fact, I believe that it is the same as the "manageability 
> capabilities" of MUWS, but adds the abstract semantic 
> definition (information modeling) on top.  Of course, I may 
> be totally wrong in this and need to be reset.

I think "Manageability Representation" (MR) should be defined in the
glossary consistent with MUWS and "Manageability Capabilities". You
should have an e-mail from me as a response to your last mail on that
thread.

> 
> 2. I think that it is problematic to have a central term,
> "manageability representation", and headings that use this 
> term, 2.1 Manageability Representation and 2.1.3 
> Representation.  The entire document is about "manageability 
> representation".  We need to rename sections 2.1 and 2.1.3 
> (perhaps to "Model" and "Capabilities and Perspectives", 
> respectively??). 

I think that 2.1 can stay the same or perhaps clarified to MR Topics -
all the subsections are simply requirements grouped by topic of
category. Your right about 2.1.3 however and we need to either change
this to model (but that is so overloaded). The other option is to move
these to Overall section 2 as a subsection called Representation
specific. I think prefer the latter but happy to hear other suggestions.
The most important fact is that we have them captured and not how they
are categorised or where they appear.

> 
> 2. Page 8, Overall 1 - The requirement distinguishes between
> "management and provisioning". It seems that management 
> includes provisioning. Should provisioning instead be 
> specifically added to the list of capabilities in Overall 3?

Igor can you reword this to be consistent with what's been put into
MUWS.
> 
> 3. Page 5, last paragraph (continuing on page 6) - This text
> does not seem to fit in a "glossary" section.  It should be 
> moved/removed.

This is an open item and Igor William and I are trying to come to 
consensus on this.

> 
> 4. Page 8, Overall 2 - Clarify that a "specific model
> representation" is really a specific "data model" 
> representation and the example is "(e.g., CIM-XML)" and not 
> CIM directly.  In fact, CIM itself IS expressed as a 
> UML-based model - since MOF is only a textual rendering of UML.

I still think [Overall 2.] is right, but feel free to retort  - the
model we will come up with will be pure UML that includes both data
(properties), behaviour (operations) and events. This can be further
rendered into a CIM model and then as CIM-XML, however I missing
something about CIM models here? 
<arw> The distinction 


> 
> 5. Page 8, Met 1 - Is the MUST requirement that metrics exist
> but that they may only be defined in specific data models?  
> Otherwise, I think that we have to define some base metrics 
> and their semantics.  It does not make sense to say that the 
> representation MUST have metrics, but that none are specified 
> in the UML abstraction.  Since Met 1 is a MUST, doesn't this 
> mean that there is some minimum set of metrics (defined in 
> support of Met 6) that MUST be implemented?  If so, we should 
> be explicit about this in the requirements.


Met 1 says the model must support the concept/definition of metrics and
allow them to be tracked. When  we define the model we may decide there
is a minimum set that have to be supported, Met 6 is stating that, but
the specification will determine exactly what that KEY set is.  
> 
> 6. Page 9, Mod 6 - Can this be clarified to indicate that we 
> are talking about information encoding and wire transmission 
> (ie, bindings)? Perhaps saying "The manageability 
> representation MUST NOT be tied to a specific XML Schema 
> representation, binding and/or interface"?? 

I think that's what it says, and relates to Overall 2, but if its not
clear how about..
"The manageability representation MUST NOT be specific to a particular
data or interface representation."

It may actually be a dup of Overall 2 and could be scrubbed?

> 
> 7. Page 10, Chng 6 - The text "all or nothing" reads to me as 
> transactions.  This seems to indicate that transactions 
> SHOULD be discussed in MUWS. If something else was intended, 
> this is not clear.

The changes that are defined can simply be grouped such that they are
determined to be related and all occurred as a result of one action,
this is a notification not an action remember.

> 
> 8. Section 4 should be removed in lieu of explicit references 
> to MUWS. If we want to further clarify MUWS requirements or 
> make them stronger (SHOULD to MUST), then we should reference 
> the MUWS requirement directly.  I don't think that it is 
> acceptable for MOWS to dictate a MUST or SHOULD that it not 
> at least a SHOULD or MAY in MUWS. 


Agreed  - we need to remove this and pass it onto MUWS editors such that
they can ensure they are covered in MUWS requirements.
> 
> 9. There are some grammar issues:
> - Page 4, First paragraph - Should end with ":" since the following 
> 	sub-headings supply the info indicated in the sentence
> - Page 4, under "deliverables" sub-heading - Should be a period after
> 	Jan 2004, and "this includes ... " should be the start of a new
> 	sentence (with appropriate capitalization)
> - Page 4, second sentence under "Initial Focus" - Is a run-on 
> and "address"
> 	should be changed to past tense.  The sentence should 
> be rewritten
> 	as "However, it is expected ... will also need to be addressED
> 	in the tenure of the WSDM TC. These include, but are ..."
> - Page 5, second paragraph under "WSDL described web service" 
> - "endpoint"
> 	in the second sentence should be plural (ie, "A binding, ..., is
> 	accessible via one or more endpointS ..."
> - Page 9, Mod 1 - Remove the "a" before "consumer"
> - Page 10, Life 7 - Suggest rewording as follows: "The manageability
> 	representation SHOULD support a "ping" to a Web service that
> 	does not change the service's state"
> 
> 10. One item needs clarification:
> - Page 10, Life 8 - Needs to be rewritten as a sentence with a MUST.
> 

Igor  - these are all your!!!

> Andrea
> 
> 
> 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/wsdm/members/leav
e_workgroup.php.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]