Everything is an Object

Everything is an Object

Cisco Open NX-OS is ob​ject-ori​ented, and every​thing within the model is rep​re​sented as an ob​-ject. Ob​jects store the con​fig​u​ra​tion or op​er​a​tional state for Open NX-OS fea​tures as​so​ci​ated with the data model. Within the model, ob​jects can be cre​ated in ref​er​ence to other ob​jects.

Ref​er​ences may be among var​i​ous net​work​ing con​structs, such as in​ter​faces and VLANs, as well as re​la​tion​ships be​tween these com​po​nents. Trunked VLAN in​ter​faces rep​re​sent an ex​am​ple of re​lated, hi​er​ar​chi​cal ob​jects.

The fol​low​ing sec​tion out​lines how MOs are de​fined in Open NX-OS dur​ing the soft​ware de​vel​-op​ment process.

MO Definition

Open NX-OS soft​ware de​vel​op​ers de​fine mod​els for var​i​ous classes in an XML for​mat, and use a mod​el​ing schema with var​i​ous tags to de​note spe​cific at​trib​utes of the class. This re​la​tion​ship is de​fined prior to com​pile-time and is en​forced dur​ing run time. How​ever, it is only the re​la​tion​-ship that we cre​ate when defin​ing the model and prop​er​ties of each MO.

Class model definition

<model>

<package name="aggregate">

<objects>

<mo name="ControllerTable"

MO Properties

On a Cisco Nexus switch, the con​fig​u​ra​tion and/or op​er​a​tional state of the net​work can be stored in the MO as prop​er​ties of the MO. Some prop​er​ties can be used to store con​fig​u​ra​-tion state, such as en​abled/dis​abled state and at​trib​utes of pro​to​cols, while other prop​er​ties can be used to store op​er​a​tional state, such as sta​tis​tics, faults, events, and audit trails.

Prop​er​ties within MOs will have an at​tribute.

propertyname="attribute"

Val​ues can be ex​pressed in terms of reg​u​lar ex​pres​sions, etc. Thus, one can ac​tu​ally spec​ify that a cer​tain prop​erty can have a string as its value only if that string matches a par​tic​u​lar reg​u​lar ex​pres​sion. All type/regex check​ing is done prior to cre​at​ing an MO and stor​ing the value as one of its prop​er​ties.

Each class is part of a pack​age, and the de​f​i​n​i​tion of the class in​cludes the pack​age name. Each class has a mo name that iden​ti​fies the class. Ref​er​ences to an MO in the cur​rent pack​age can be made by di​rectly spec​i​fy​ing the name of the MO. Any ref​er​ence to an MO in a dif​fer​ent file/pack​age will have to pre​fix the ref​er​ence with the pack​age name of the MO being re​ferred.

Any ref​er​ence from an ex​ter​nal pack​age to the con​trollerTable MO, in the Class model de​f​i​n​i​-tion ex​am​ple above, should be for​mat​ted as ag​gre​gate: con​trollerTable, where con​trollerTable is the class name and ag​gre​gate is the name​space qual​i​fier. This en​sures you are using the right class while ref​er​enc​ing it in some other pack​age.

MO Inheritance

Each ob​ject within the data model is an in​stance of its as​so​ci​ated class. The ob​jects in the model can use the con​cept of in​her​i​tance, which al​lows for new ob​jects to take on prop​er​ties from ex​ist​ing, more ab​stracted base ob​jects. For ex​am​ple, a phys​i​cal in​ter​face can be a data port or a man​age​ment port; how​ever, both of these still have the same basic prop​er​ties, so they can in​herit from a sin​gle in​ter​face base class. Rather than re​de​fine the same prop​er​ties many times, in​her​i​tance can be used to de​fine them in one base class, and then cus​tomize them for a spe​cific child class.

A class can be de​fined as a purely ab​stract class by set​ting the concrete=yes/no at​tribute to concrete=no. Such classes are purely ab​stract - no ob​jects of the class can be in​stan​ti​ated.

Other non-ab​stract, con​crete MO can ref​er​ence the ab​stract MO as a “super class” and in​-herit the class prop​er​ties.

Fig​ure: Par​ent-Child In​her​i​tance Re​la​tion​ship in Open NX-OS Data Model