RE: Proposal [Disc05] (was: RE: [wsdm] Proposal on [Disc04])

["Vambenepe, William N" <vbp@hp.com>]

Sounds good. So, unless someone else has additional comments on [Disc04]
(if so please reply to this email) it will join the group of discovery
issues hibernated until the relationship work is completed.

Regards,

William

> -----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: 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.