OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsdm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [wsdm] Terminology in the requirements


Title: Message
Actually, your points are valid but perhaps too restictive.  I agree that both may exist, but from a MUWS perspective, the only thing that is important is the management interface to the object. We really shouldn't be exposing this much about the architecture.  
 
Assume that a dashboard gauge represents the implementation of the management interface.  If the gauge on your dashboard showed the battery voltage at zero, you can't always assume that battery is dead.  It could be that the gauge is broken, that the sensor to the battery is broken, or that the sensor is only active if the car is on... You can create other management entities to identify the cause of the problem, the guage could provide an interface to it to check its validity as could the battery sensor and the car in general but you wouldn't ask the battery gauge to implement all of these.
 
As above. in your example, the provider to the management service failed.  Having this provider as another managed object creates the ability to see this failure.  But some objects may have different models, for example be self managing (ala SNMP) or aggregations across a number of objects or federated and so on...  These don't necessary have "an" agent, do we want to require that they implement one so we can watch for it to fail? 
 
RN
 
 
-----Original Message-----
From: Aganagic, Muhamed [mailto:muhamed.aganagic@intel.com]
Sent: Monday, August 11, 2003 12:12 PM
To: Nikula, Richard; Wsdm (E-mail)
Subject: RE: [wsdm] Terminology in the requirements

Richard,

 

I suppose what I was driving at is that we need the both. This is perhaps why we are "bouncing" between the two. In other words, we need to think about the management interfaces of the managed objects (platforms, DB, etc.) as well as the ones of the management artifacts (agents, monitors ... as well).

 


One could say why don't we just treat them as managed objects?  I suppose this is always an option. What is lost is the fact that there is dependence between the two.

For example, when an agent goes down, all the interfaces that are provided by it will stop working while the managed objects' interfaces are all operational. If we don't make the distinction we cannot distinguish between this failures and failure of the managed objects. Consequently, our management capabilities would be diminished (we could not, say try to fix the agent).

 

I apologize if, as a new-comer to this forum, I am not well aligned with the team. I'll promise to cut this thing here.

 

Aga

 

______________________________
Muhamed Aganagic, Ph.D.
Intel Corporation
Enterprise Platforms Group
Advanced Systems Development
Director of Technology
SC12-320,
3600 Juliette Lane
Santa Clara, CA 95054
Office: 408 765 7025;
Mobile:408 718 4911

-----Original Message-----
From: Nikula, Richard [mailto:Richard_Nikula@bmc.com]
Sent
:
Monday, August 11, 2003 6:40 AM
To: Wsdm (E-mail)
Subject: RE: [wsdm] Terminology in the requirements

 

My 2 cents on this.  I think part of our terminology problem stems from the overlap with existing terminology.  For example, is an object or resource managed by a CIMOM or SNMP a managed object or managed resource?  I think most would think so. Since one of our requirements is that a web service exists to support the object or resource, that our focus is not on the object but rather on the interface to the object.  Thus the definitions sent by Mark are reasonably good because they don't even try to define what a resource is, only the managability requirements.  We bounce back and forth between a managed object providing management and perhaps a 3rd party or agent providing the management for it but it really seems like we don't care as long as the management interfaces exists.  Thus, it would seem that the requirements should be worded accordingly.

 

A MUWS management interface MUST expose ....

 

Richard

-----Original Message-----
From: Aganagic, Muhamed [mailto:muhamed.aganagic@intel.com]
Sent:
Friday, August 08, 2003 11:16 AM
To: Sedukhin, Igor S; homayoun@hp.com
Cc: wsdm@lists.oasis-open.org
Subject: RE: [wsdm] Terminology in the requirements

In my experience, it is useful, if not necessary, to distinguish between the instrumentation (and/or management infrastructure) and managed objects.

This is because one has to think and plan for management of the instrumentation as well; the corresponding software needs to be provisioned and patched, monitors fail and agents need to be restarted,

alerts have to be raised because instrumentation is failing, etc.  I

 

 

______________________________
Muhamed Aganagic, Ph.D.
Intel Corporation
Enterprise Platforms Group
Advanced Systems Development
Director of Technology
SC12-320,
3600 Juliette Lane
Santa Clara, CA 95054
Office: 408 765 7025;
Mobile:408 718 4911

-----Original Message-----
From: Sedukhin, Igor S [mailto:Igor.Sedukhin@ca.com]
Sent:
Thursday, August 07, 2003 5:40 PM
To: homayoun@hp.com
Cc: wsdm@lists.oasis-open.org
Subject: RE: [wsdm] Terminology in the requirements

 

Homayoun,

 

In this case my concern is only the way the requirement is stated in the document and the words in the definition. When I showed our MUWS reqs document to other people this is how they interpret it back to me.

 

In general, instead of arguing about the semantics why don't we just relax the definitions that we use.

-- Igor Sedukhin .. (igor.sedukhin@ca.com)
-- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788

-----Original Message-----
From: M. Homayoun Pourheidari [mailto:homayoun@hp.com]
Sent:
Thursday, August 07, 2003 6:42 PM
To: Sedukhin, Igor S
Cc: wsdm@lists.oasis-open.org
Subject: Re: [wsdm] Terminology in the requirements

Igor, et. al

Although I agree with your general comment that we don't want to limit ourselves to a traditional agent based model, I do not agree with your interpretation of what a managed object means.  In fact, the term "managed object" is used to generalize on the manageability representation and interfaces of a resource that is managed without promoting an agent based or agent less model and I don't interpret the use of "managed object" as you described it.

Nonetheless, I'm not religious about these things. 

Cheers,
H.
--

Sedukhin, Igor S wrote:

We have a problem in agreeing to the requirements that state "managed object MUST expose <whatever>". It prescribes certain way of doing management. These requirements are on the "The software component representing or part of the manageable resource responsible for interacting with the manager is referred to as the managed object in this document. Traditionally, such software is also known as agent."

We do not want to be limited by defining requirements on management using agents as suggested.

We propose to use more generic phrasing around ALL of such requirements. For example, We propose to phrase it as follows "<whatever> MUST be provided for a manageable resource". This phrase says WHAT instead of implying HOW.

PS. By "we" here I mean CA. And this is a violent objection :).

-- Igor Sedukhin .. (igor.sedukhin@ca.com)
-- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788



-- 
M. Homayoun Pourheidari
Web Services Management Operation
HP OpenView Division
408.447.5012
homayoun@hp.com


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]