[cddlm] MUWS and MOWS

[Stuart Schaefer]

Steve,

I think you should check this with the WSDM guys, but this is from WSDM
MUWS Part 1.0, Chapter 6.  I read it to say that only the Identity
capability is required.


"Implementers of manageability endpoints are free to expose additional
manageability capabilities beyond those defined in MUWS. An additional
capability is represented by a set of manageability capability
interfaces. The properties defined in a new capability must be defined
as XML Schema 
Global Element Declarations. The operations defined in a new capability
are represented as WSDL 1.1 operations. Furthermore, a manageability
endpoint offering a new capability is free to ignore all standard
manageability capabilities defined by MUWS except for the Identity
capability. 811
The MUWS Identity capability is REQUIRED. "


Chapter 5 seems to indicate that Identity, ManageabilityCharacteristics,
and CorrelatableProperties are required, but again Chapter 6 seems to
countermand that.

For lifecycle representation, I would prefer you to use the
cmp:lifecycle definitions.

In regards to the MOWS stuff, you don't have to purge it.  You could use
it.  I made it completely optional in the component model.  You may
choose to use it, since you are exposing web services such as the Portal
EPR.

Stuart

-----Original Message-----
From: Steve Loughran [mailto:steve_loughran at hpl.hp.com] 
Sent: Wednesday, May 18, 2005 12:47 PM
To: 'cddlm-wg at ggf.org'
Subject: [cddlm] MUWS and MOWS


OK, I think I understand it better; the cmp XSD is helping me to get to 
grips with this.

to be MUWS, we appear to need

0. properties as WSRF properties
1. an identity (URI)
2. some XML document declaring our capabilities (how this gets to the 
system is out of band)
3. an operational status attribute
4. optional: a state derived from the muws state stuff
5. events for changes in (3) and (4) that are derived from the muws
events

I am thinking that I must describe the state of the systems using the 
cmp: lifecycle, and have matching events, but declare that transition 
operations are queued requests

-it isnt an error to send >1 state changing operation to a system EPR, 
when it is in a valid state for that request
-it is an error to send a state changing operation to a system EPR when 
it isnt in a valid state for it
-you can send terminate requests to terminated systems.
-The OperationalState of a system is "operational" only when in the 
running state.

I'll then purge all MOWS stuff (GetManageabilityReferences &c).


is this right?

-steve