RE: [wsdm] [MUWS Spec] general comment - need to be decided by 1.0 at the latest

["Sedukhin, Igor S" <Igor.Sedukhin@ca.com>]

It seems that it could be sufficient that MUWS spec merely says what is mandatory to implement when describing the capabilities. For example it may say that Identioy is required for any resource (I believe it says so now). It would then have a similar statement in Resource State section saying that it is mandatory to derive from the top three states, and so on.

I'm not sure there needs to be a separate section that calls out all the above assetions. 

-----Original Message-----
From: John DeCarlo [mailto:jdecarlo@mitre.org] 
Sent: Tuesday, March 16, 2004 2:35 PM
To: WSDM TC
Subject: [wsdm] [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



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/leave_workgroup.php.