What I mean by "dead" is that the scope changes only if a resource
becomes completely inactive (e.g. a power cycle). If it is just
dormant, then after it becomes active, there is no change of scope. A
consumer (manager) should be able to tell the difference when something
is just dormant or gone.
H.
---
Sedukhin, Igor S wrote:
oh, so you want it dead :):).... say it pretends really well do
be dead... there is no way to tell from the consumer's prespective and
that is what matters: activity of the implementation of a manageable
resource from the POV of the manageability consumers.
"managed resource" should be changed to
"manageable resource" as defined
in the MUWS spec.
"go up and down" was the only way I could think of to describe that a
resource may be alive or not. I am open to suggestions...
I used the term "managed domain" since there seemed to some specific
interest in this term. Nonetheless I am also more comfortable with the
term "managed scope". The term "management scope" gives me the
impression that the scope of the manager is also part of it -- which is
not.
"activity scope" could mean that something is active and then dormant
for a while (not necessarily dead). Hence, I am not comfortable with
this term.
Cheers,
H.
--
Sedukhin, Igor S wrote:
>1. "managed resource" needs to be defined. It is not defined in MUWS
>now.
>2. "go up and down" needs to be defined. It is not clear what that
is.
>We may all be thinking of different things reading it.
>4. "managed domain" or "management domain" or "manageability
domain"?
>Which would be the right term here? This seems more like "management
>scope" than a "domain".
>5. Creation of "managed domain" is a bit confusing, IMO.
>
>I suggest that we simply say "Event identifiers are unique for only
the
>activity scope of the implementation of the manageable resource
which
>observers the events. That is, if activities of an implementation
of a
>manageable resource are interrupted, such as due to a power cycle,
the
>activity scope is terminated. After that, event ideftifiers would be
>unique to another activity scope of the same implementation of a
>manageable resource.
>
>
>
>-- Igor Sedukhin .. (igor.sedukhin@ca.com)
>-- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11749
>
>
>-----Original Message-----
>From: Homayoun Pourheidari [mailto:homayoun@bea.com]
>Sent: Monday, November 15, 2004 3:30 PM
>To: wsdm@lists.oasis-open.org
>Subject: [wsdm] managed domains and unique event identifiers
>
>Hi,
>
>Below is a porposed text to describe managed domains and the unique
>event identifier requirements for wsdm events.
>
>Cheers,
>H.
>--
>
>A managed resource may go up and down many times during its life
cycle.
>
>Every time that it is alive or up, it has an associated scope that
>includes all state and property values of the resource among other
>manageability information. We call this scope the managed domain
of a
>resource.
>
>For all events associated with the scope of a resource, all
>notifications that describe the events and are created to report
them,
>must have unique identifiers. The identifiers are not required but
may
>also be unique globally across the collective managed domains of
all the
>resources that a manager is managing.
>
>When a resource is forced to restart its scope (e.g. goes down and
comes
>back up) a new managed domain for that resource is also created.
WSDM
>does not require that notification ids produced in the latter
managed
>domain to be unique across the current and the former managed
domains of
>the resource. However, more capable managers may provide ways to
>preserve some continuity of scope between various instantiations of
a
>resource's managed domains as a way of providing a longer
perspective on
>the life cycle of a managed resource. Unique identifiers for
>notifications across all of the managed domains of a managed
resource
>may be one such candidate for continuity.
>
>
>
>
>
>
>
|