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: [MUWS Spec] general comment - need to be decided by 1.0 at the latest


Hello,

I earlier made a comment about wording in MOWS, section 2.2, about the 
optional dependency on MUWS.  Namely,

"The endpoint manageability capability may depend on a common 
manageability capability. This dependency is optional, however. The 
dependency could be an explicit extension of a common capability which 
makes it more specific. For example, a common manageable state 
capability may represent an ability to express UP/DOWN states, and an 
endpoint manageable state capability may add an ability to represent 
IDLE/BUSY/SATURATED, and other endpoint-specific states. This could be 
expressed by an endpoint manageable state UML model (class) that extends 
the common manageable state UML model (class). There could be cases 
where the extension is implicit. For example, a UML model of the 
endpoint manageable metrics capability could use some of the data types 
expressed in the common manageable metrics UML model (e.g., Counter data 
type), but the capability model itself does not have to mandate the 
extension of the whole common capability model. That is, the endpoint 
manageable metrics capability can be supported on its own without the 
need to support the common capability. There also could be cases when an 
endpoint manageability capability is a new one, available for web 
service endpoints only, and there is no dependency on the common 
capability. This is why the dependency is optional."

However, it seems to me that the MUWS specification needs to have some 
words about how it impacts the various resource domains, like MOWS.

"When making an IT Resource manageable using Web services, the following 
items are required to be implemented by the manageability provider 
(bulleted list or references to sections) and the following items are 
strongly urged to be implemented, knowing that there are some IT 
Resource domains where it can not be:  (bulleted list)."

It could go on to talk about capabilities that are more specific, are 
similar but have different names, etc.

But we need to have agreement on this, at least by 1.0.

For instance, on Resource State.  Will it be legal for a manageability 
provider to implement 5 top level states or are we requiring every 
manageability provider to implement 3 top level states, only valid 
transitions, and may extend only by implementing sub states of the 3 top 
level states?

We have talked about this, but at some point the document will need to 
be absolutely clear and match up with MOWS.

Thanks.


-- 

John DeCarlo, The MITRE Corporation, My Views Are My Own




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