[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Methods in the NIM requirements
Walter,
First - a question to you: "Why put any data/method design decisions into an
info model requirements document?" I see the need to say that data and
methods exist - these are the requirements of the model. But, describing
"how network data is modeled" USING the info model is a different beast
altogether.
Now, to answer your questions ....
As rules of thumb:
- Class properties represent "data" (Status, CurrentQueues, Counters, etc.).
- Class methods represent "behavior" (Reconfigure, Save/RestoreState,
Initialize, etc.).
However, it is up to the NIM WG (if one forms) to decide if these rules of
thumb should be overridden in specific scenarios.
Why separate data and methods?
This allows a clear modeling separation between:
- State information and operational constraints (data)
- Configuration information (more data, since it is different than state
until the configuration is applied, since even after config application -
state can be different, and since different configurations can be defined),
and
- The activities of configuring/resetting/... with known required/input
data, known output data, return codes, etc.
Even if a specific repository/protocol does not support methods formally,
the data model mapping would define how to set the parameters, and what to
check to determine the return code. Or, if not supported, then this would
be indicated by the mapping/implementation.
Please note that I am not including data read/write as info model
methods/BEHAVIOR. These are just operations on the data, where the data
itself would indicate its R/W characteristics. I would assume that each
repository/protocol has its own mechanism for read/write, and that this is
addressed in the mapping of the info model to the specific data model.
Andrea
> -----Original Message-----
> From: owner-nim@ops.ietf.org [mailto:owner-nim@ops.ietf.org]On Behalf Of
> Weiss, Walter
> Sent: Friday, April 28, 2000 2:22 PM
> To: nim@ops.ietf.org
> Subject: RE: Methods in the NIM requirements
>
>
> Andrea and Lakshmi,
>
> Seeing that you believe both methods and attributes should be available, I
> am concerned that the choice of when methods should be used and when
> attributes should be used appears to be a matter of opinion. This suggests
> that clear guidelines for the applicability of methods and
> attributes should
> be included in the requirements document. Could you provide your
> position on
> when each should be used and why.
>
> To make sure we all understand eachother, I would like to use the existing
> BandwidthScheduler class that has already been proposed for the QoS Device
> Model. This class represents a bandwidth scheduler, which is a
> process that
> reserves a portion of the bandwidth of a link for each selected traffic
> type. Could you use this example and describe where you believe
> methods are
> appropriate and where attributes are appropriate? It would also be helpful
> if you actually included the signatures. We will no doubt need to agree on
> the requirements for method specification as well.
>
> BandwidthScheduler
> BandwidthAllocation: uint32
> Defines the number of bytes that can be delivered from
> a queue each cycle
> BurstsAllowed:boolean
> This is a boolean attribute which, if TRUE, signifies
> that a temporary or short-term allocation of additional
> bandwidth in addition to the amount of bandwidth
> allocated through the BandwidthAllocation attribute
> is allowed.
> BurstAllocation: uint32
> Specifies the amount of temporary or short-term
> bandwidth that can be allocated beyond the amount of
> bandwidth allocated through the BandwidthAllocation
> attribute. If the maximum actual bandwidth allocation
> were to be measured, it would be the sum of the
> BurstAllocation and the Bandwidth allocation attributes.
> CanShare: Boolean
> This is a boolean attribute that, if TRUE, enables
> unused bandwidth from the associated queue to be
> allocated to queues that need additional resources.
> WorkConserving: Boolean
> This is a boolean attribute that, if TRUE, prevents
> the scheduler from bursting traffic from the queue to
> which this instance of the scheduler is associated. When
> TRUE, this attribute also prevents bandwidth from other
> idle queues to be consumed by the current queue, thereby
> preventing resource allocations above the assigned
> bandwidth.
>
> regards,
>
> -Walter
>
> > -----Original Message-----
> > From: Andrea Westerinen [mailto:andreawest@mindspring.com]
> > Sent: Tuesday, April 25, 2000 1:41 PM
> > To: Lakshmi Raman; Weiss, Walter
> > Cc: Joel M. Halpern; nim@ops.ietf.org
> > Subject: RE: Methods in the NIM requirements
> >
> >
> > I totally agree with Lakshmi. Attributes represent state/data (ie,
> > DeviceIsLocked boolean, CurrentNumberOfQueues guage, etc.).
> > This should be
> > defined as properties in the info model. It is very
> > reasonable to have
> > public data in an OO design. Methods represent behavior and
> > change state
> > (ie, InitializeDevice, Reconfigure, etc.).
> >
> > To mix the concepts of data and methods ends up with data
> > acting as a method
> > (ie, write property x, hope that it takes, come back later to
> > verify, if the
> > value changed was it because of the write or something else),
> > or (OTOH)
> > methods that are very numerous and/or cumbersome.
> >
> > A word of caution - Don't mix different implementation views
> > (all data, all
> > methods, or various mixes of data/method combinations) into
> > the info model
> > view. An info model is (by definition) repository and implementation
> > independent. That indicates that we should define the right level of
> > "public" data and the right methods to reflect behavior and
> > change state.
> > Then, the various implementations should map these to what
> > they understand
> > and require.
> >
> > Andrea
> >
> > > -----Original Message-----
> > > From: owner-nim@ops.ietf.org
> > [mailto:owner-nim@ops.ietf.org]On Behalf Of
> > > Lakshmi Raman
> > > Sent: Saturday, April 22, 2000 2:28 PM
> > > To: Weiss, Walter
> > > Cc: Joel M. Halpern; nim@ops.ietf.org
> > > Subject: RE: Methods in the NIM requirements
> > >
> > >
> > >
> > >
> > > Walter
> > > I do not think it is correct to say that we do not need
> > > attributes if we have
> > > methods.
> > > They are both needed. Often attributes represent states that an
> > > object goes
> > > through
> > > when different methods are invoked and these are properties
> > that should
> > > be readable.
> > > Lakshmi
> > >
> > >
> > >
> > >
> > > "Weiss, Walter" <WWeiss@lucentctc.com> on 04/19/2000 04:22:15 AM
> > >
> > > To: "Joel M. Halpern" <joel@ivyplan.com>, nim@ops.ietf.org
> > > cc: (bcc: Lakshmi Raman/Telcordia)
> > > Subject: RE: Methods in the NIM requirements
> > >
> > >
> > >
> > >
> > > > When I build actual objects, I almost always hide the attributes
> > > > completely, and use specific accessor operations. But that
> > > > is not because
> > > > I want to hide the existence of the attribute. It is because
> > > > the languages
> > > > all end up exposing more than just the attribute when I expose an
> > > > attribute. To retain my flexibility of implementation, I
> > > > hide that under
> > > > an accessor. But in the kind of information model we are
> > > > talking about, we
> > > > do not have this drawback. So we can use the power of both
> > > > the attriubte
> > > > semantics and the operational (method) semantics where each
> > > > is appropriate.
> > >
> > > Joel,
> > >
> > > It would seem then that attribute constraints are
> > unnecessary because the
> > > the method definitions provide those constraints as part of their
> > > definition. Why bother defining attributes at all if you have method
> > > definitions to specify the behavioural boundaries of the object?
> > > As you say,
> > > the attribute definitions within an object define a specific
> > > implementation
> > > of the object that is immaterial to the interface definition.
> > >
> > > regards,
> > >
> > > -Walter
> > >
> > >
> > >
> > >
> > >
> > >
> >
>