RE: [wsdm] Proposal on [Disc05]

[Tom Maguire <tmaguire@us.ibm.com>]

"Sedukhin, Igor S" <Igor.Sedukhin@ca.com> wrote on 06/14/2004 05:27:19 PM:

> Here is a rephrased proposal for the Correlateable Properties capability.
>
> X. CorrelateableProperties manageability capability
>
> This capability allows a manageabilty provider to expose its
> understanding of what property values could be used to establish
> that both this and another manageability provider are enabling the
> same manageable resource.

Don't you mean that a provider who is exposing property values could
logically annotate the resource property elements to provide additional
meta-information about which resource property elements and
their respective values COULD be used to determine correlation of
manageable resources?

btw, if it is just a COULD how useful this capability?

> For example, one provider may enable
> temperature control capability for a SCSI HDD and another provider
> may enable capacity management capability for the same SCSI HDD.
> Each provider may generate its own unique muws-xs:ResourceID due to
> the implementation requirements or constraints (e.g. firmware).
> However, providers may be aware of some unique resource-specific
> property values which indicate if the resource is the same or
> different. In the SCSI example, it could be host IP, bus #, channel
> #, SCSI ID, LUN ID. If those properties match, one could be
> generally certain that per SCSI resource definition manageability is
> provided for the same SCSI resource.
>
> Using this capability both providers may expose their understanding
> of what resource property values need to match to establish the
> correlation between manageable resources. The manageability consumer
> uses this information to evaluate and establish the correlation.
>
> X.1. Data Types
>
> There are data types defined in its own namespace (pbm) to provide
> for simple boolean property match dialect. It is defined as follows.
>

You will need to normatively describe all of the matching rules for
all of the potential datatypes of resource properties.
Additionally, how would you handle (in this dialect) matching on
resource property elements where maxoccurs is greater then 1?
Is a complete match sufficient?  Can just one of the values match?

> <pbm:Match>xsd:QName</pbm:Match>
>
> True if values of the property identified by the given QName
> matches. Fetch the property and compare the values.
>
> <pbm:MatchAny>(<pbm:Match/>|<pbm:MatchAll>)*</pbm:MatchAny>
>
> True of any of the enclosed match conditions are true. Evaluate
> enclosed match conditions.
>
> <pbm:MatchAll>(<pbm:Match/>|</pbm:MatchAny>)*</pbm:MatchAll>
>
> True if all of the enclosed match conditions are true. Evaluate
> enclosed match conditions.
>
> X.2. Properties
>
> <CorrelateableProperties
Dialect="xs:anyURI">...</CorrelateableProperties>*
>
> This property indicates the manageability provider's view on what
> property values and/or consitions and/or expressions could be used
> to correlate manageable resources. Depending on the Dialect it could
> be as follows.
>
>    Simple Property Boolean Match (Dialect="http://docs.oasis-open.
> org/wsdm/2004/09/pbm). The contents of the property is as described
> in section X.1. If all simple property boolean match conditions are
> evaluated true, the correlation between manageable resources is
established.
>
>    XPath 1.0 (Dialect="http://www.w3.org/TR/1999/REC-xpath-19991116
> "). The contents of the property is an XPath 1.0 expression. If
> XPath expression evaluates to a non-empty value or true without any
> errors, the correlation between manageable resources is established.
>
> There could be dialects not known or defined by this specification.
> It is the manageability provider's responsibility to include
> dialects it is capable of working with. There could be more than one
> dialect provided by the same manageability provider and for the same
> sort of resources. For example, a manageability provider for a SCSI
> HDD may expose two values of the CorrelateableProperties property --
> one with simple boolean match dialect and another one with Xpath
> dialect. The manageabilty consumer may evaluate any dialect that it
> understands.
>
>
> -- Igor Sedukhin .. (igor.sedukhin@ca.com)
> -- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788
>
> -----Original Message-----
> From: Andrea Westerinen [mailto:andreaw@cisco.com]
> Sent: Thursday, June 10, 2004 2:22 AM
> To: Sedukhin, Igor S; 'Vambenepe, William N'; wsdm@lists.oasis-open.org
> Subject: [wsdm] Proposal on [Disc05]
>
> I think that the difference is more basic than known or not known by
> a provider.  The difference is known and published by a provider
> (and perhaps only known by the provider using some magic sauce)
> versus known by examining intrinsic/basic data.  However, even this
> proposal leads to further questions that can only be answered by a
> consistent backing model (like CIM).
>
> Let me explain further ... Igor's proposal is ok with me at a
> conceptual level, but what happens when provider 1 lists all the
> properties below, but provider 2 only lists ID and
> LogicalUnitNumber.  Is provider 2's ID the same as provider 1's
> BusID, ChannelID or just ID?  What if it is all 3?  Is
> LogicalUnitNumber the same as LUN?  Most likely, but a program
> doesn't know this, only a person. What if provider 2 also lists the
> foo attribute?  So, we make progress with an element like
> CorrelatableProperties, but we need CIM to use it.
>
> Lastly, we have to convey that this is meta-data tied to the data of
> the backing model, not raw intrinsic information.
>
> Andrea
>
> > -----Original Message-----
> > From: Sedukhin, Igor S [mailto:Igor.Sedukhin@ca.com]
> > Sent: Wednesday, June 02, 2004 9:09 AM
> > To: Vambenepe, William N; wsdm@lists.oasis-open.org
> > Subject: [wsdm] RE: Proposal [Disc05] (was: RE: [wsdm] Proposal on
> > [Disc04])
> >
> >
> > Ok, so be this my proposal to close [Disc05]. I guess it was not clear
> > to me as to what is the difference between 05 and 04, but that is ok.
> > Now I see that
> >    04 - if such relationship is known by providers
> >    05 - if such relationship is NOT known by providers
> >
> >
> > -- Igor Sedukhin .. (igor.sedukhin@ca.com)
> > -- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788
> >
> > -----Original Message-----
> > From: Vambenepe, William N [mailto:vbp@hp.com]
> > Sent: Tuesday, June 01, 2004 6:22 PM
> > To: Sedukhin, Igor S; wsdm@lists.oasis-open.org
> > Subject: Proposal [Disc05] (was: RE: [wsdm] Proposal on [Disc04])
> >
> >
> > Hi Igor,
> >
> > I agree with you. The "relationship" approach only works if the person
> > we are talking to has knowledge of the other manageability
> > endpoints/representations. And you give a very good example of a case
> > where there are two manageability endpoints/representations that are
> > likely to not know about one another. All WSDM is about at the end is
> > defining interfaces. If the person you talk to doesn't have the
> > information you are asking for, no amount of clever interface design
> > will make them give you the info.
> >
> > This relationship mechanism to discover other manageability endpoints
> > is useful but is in no way guaranteed to give you the whole list.
> >
> > After this step, as you describe, we are left to using other
> > mechanisms to try to find even more manageability endpoints.
> > This is where the correlatable name mechanism might come in handy, but
> > at that point we are transitioning to [Disc05].
> >
> > So I think we are on agreement on [Disc04] (let me know if we're not)
> > and I am renaming this thread to [Disc05] as you are proposing a way
> > to solve this issue.
> >
> > You proposal to [Disc05] looks reasonable to me.
> >
> > Regards,
> >
> > William
> >
> > > -----Original Message-----
> > > From: Sedukhin, Igor S [mailto:Igor.Sedukhin@ca.com]
> > > Sent: Tuesday, June 01, 2004 8:06 AM
> > > To: Vambenepe, William N; wsdm@lists.oasis-open.org
> > > Subject: RE: [wsdm] Proposal on [Disc04]
> > >
> > >
> > > William,
> > >
> > > This will require manageability providers to know of other
> > > manageability providers for the same resource. I do not think it is
> > > always reasonable.
> > >
> > > If I implemented a co-located manageability provider that offers
> > > resource state capability for a warehouse Web service, and then
> > > someone else implemented a proxy manageability provider offering
> > > metrics capability for the same service, they are not necessarily
> > > aware of each other. Morevover, they could be developed and
> > > instrantiated completely independently of each other.
> > >
> > > So, my point is
> > >  1) relationship may be defined for the cases where providers are
> > > aware of each other
> > >  2) for the general case, in the spec, we just say a) fetch
> > > ResourceID, b) discover all manageability endpoints with a given
> > > ResourceID c) there could be more (with different
> > ResourceIDs), so use
> > > "correlatable properoperties" capability (TBD).
> > >
> > > The idea behind c) is that
> > >    - fetch all properties marked "correlatable"
> > >    - use generalized discovery to find all manageable
> > resources with
> > > matching "correlatable property" values
> > >
> > > For example, a SCSI HDD could mark the following properies as
> > > "correlatable": host DNS name/IP, Bus#, Channel#, SCSI#, LUN#.
> > >
> > > To be even more concrete I suggest to define "Correlatable
> > Properties"
> > > capability as follows :)
> > >    1) a property muws-xs:CorrelatableProperties
> > >    2) value of which follows the example below
> > >
> > >    <muws-xs:CorrelatableProperties>
> > >       <muws-xs:MatchAny>
> > >          <muws-xs:Match>scsi:HostName</muws-xs:Match>
> > >          <muws-xs:Match>scsi:HostIP</muws-xs:Match>
> > >       <muws-xs:MatchAny>
> > >       <muws-xs:Match>scsi:BusID</muws-xs:Match>
> > >       <muws-xs:Match>scsi:ChannelID</muws-xs:Match>
> > >       <muws-xs:Match>scsi:ID</muws-xs:Match>
> > >       <muws-xs:Match>scsi:LUN</muws-xs:Match>
> > >    </muws-xs:CorrelatableProperties>
> > >
> > >    3) no events or operations are necessary
> > >
> > > -- Igor Sedukhin .. (igor.sedukhin@ca.com)
> > > -- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788
> > >
> > > -----Original Message-----
> > > From: Vambenepe, William N [mailto:vbp@hp.com]
> > > Sent: Friday, May 28, 2004 6:21 PM
> > > To: wsdm@lists.oasis-open.org
> > > Subject: [wsdm] Proposal on [Disc04]
> > >
> > >
> > > Hi all,
> > >
> > > As promised, here is a proposal for [Disc04].
> > >
> > > > [Disc04]
> > > > From one manageability endpoint to other manageability
> > endpoints of
> > > > the same resource (to discover all the manageability capabilities
> > > > offered), including endpoints from the same and different
> > > > manageability Providers.
> > > > We discussed that one 2 weeks ago but didn't talk about
> > any way to
> > > > address it yet.
> > >
> > > This proposal too rests on using relationships. It is
> > simply to create
> > > a special relationship type, called something like
> > "sameResource" or
> > > "alternateManageabilityRepresentation". A Ws-Resource representing
> > > resource foo will advertise this relationship between
> > itself and the
> > > other known WS-Resources that also represent foo.
> > >
> > > Simple and clean, don't you think?
> > >
> > > Therefore I propose we also hibernate this issue with the assumption
> > > that relationships will provide the right mechanism (of
> > course, to be
> > > validated once we actually have relationships).
> > >
> > > William
> > >
> > > 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.
> >
> >
> >
> > 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_workgrou
> p.php.
>
>
>
> 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.ph
> p.
>
>
>
> 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.
>
>
>
> 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.
>
T o m   M a g u i r e

STSM, On Demand Architecture
Poughkeepsie, NY  12601

internet:                 tmaguire@us.ibm.com
phone:                     845.433.9401 (t/l 293-9401)