|
A 421 page hardcover with lots of info on recent trends including CORBA, Java and the web. |
|
No ideas about this book. Anyone read it yet? |
|
Featuring original chapters from prominent experts in
the field. |
|
|
|
There are a variety of standard bodies that have been working on developing GDMO objects for several years. TMN compiles such a collection of documents. Various extensions like M4 by the ATM Forum provide extensibility to new network elements. More likely than not, your network management needs are covered by one of these existing documents. Avoid attempting to strike out on your own to develop GDMO objects. The biggest advantage to the standard documents is the tremendous amount of peer review. And these peers have extensive experience in GDMO modelling and actual product development. In addition, sticking to standard documents will help as your network management needs grow and expand. So what do you do if it is decided that your network management needs require a proprietary GDMO model? First thing is to hire someone with as much GDMO experience as possible. Do not think that you can simply sit down and start modelling objects willy-nilly and end up with something that will even work. You need someone who understands the complexity of GDMO and has sufficient development experience using GDMO objects. I have seen people attempt to develop their own objects and they were complete disasters. In particular instances, requesting the value of an object ended up with the result always being an error because the object always violated a known restriction. Obviously, this does not provide you with any network management capability. Another point that needs to be considered when developing your own object model is the development of the applications using these objects. Do not even think for a moment that the development of the applications can or should parallel the development of the object models. What might seem to the object modeller as a simple change to the object(s) can be a programming nightmare for the developer. Have your object model down and locked before starting any programming effort. I can not stress this particular point enough. I have seen project after project fall terribly behind schedule because the GDMO wasn't frozen during development. |
|
What to do if... This next section is aimed at people that still need to develop their own object models but can't find someone with GDMO experience. I will try to cover as much information here as possible. X.720 and X.722These two CCITT documents specify two important concepts, the Management Information Model and the Guidelines for the Definition of Managed Objects (GDMO). These two documents, together, should be treated as the philosophy for developing your own object model. They specify both how the objects should be developed and why. If you don't already know it, get a copy of the ASN.1 standards too. CMIPUnderstand and study CMIP. Each object's behaviour is impacted in some way because of how CMIP can or can not manipulate it. Understand the differences of simliar concepts and the underlying mechanism of the implementation. These and other concepts are the underpinning of every object model. Not understanding the concepts will render an object model useless. For example, you can create an object instance in two different ways. Why does this impact your model? Understand XOM/XMP and the particular implementation/vendor you are using. There may be additional restrictions as a result of the implementation you have decided to use. Sample ObjectThis section is incomplete. In order to understand how to apply some of the concepts present in GDMO we will create a sample object here. |
|
Overlooked concepts and mistakes What follows are some concepts to keep in mind and mistakes to avoid while developing your GDMO. These are concepts detailed in both X.720 and X.722. Default Value DefinitionsDefining default values to attributes is advantageous for several reasons. It reduces the amount of code necessary by the manager to issue a create. It also leaves the values of some attributes to be determined later. Eventhough GDMO specifies an ASN.1 methodology to use default values, many object modellers miss it. This example will show a plausible, but incorrect way of modelling a default value: DefaultPunchInTime ::= 19960101000000.0 Now the way GDMO recommends defining default values: DefaultPunchInTime ::= {none NULL} Do you see the difference in the two approaches? Do you see why one approach is also easier to understand during implementation by the programmers? The difference in the two approaches is that one provides a bogus default value that has to be hard coded somewhere during the programming effort. The first example does not accurately represent the attributes. The time example does not represent the fact that when the object is created there is no punch in time available. Neither does it represent that no first name has been provided. The second example provides explicit declarations that values have not been provided. The Counter example is diversly different in both examples. In the first example, a value of zero is the default value but tells the user nothing about the state of the counter. This creates ambiguity about the value itself. Certainly, a second attribute could be added that represents the state of the counter. The second example shows how the state of the counter is represented at the same time as it's current value. NamingDescriptive names are predominant in GDMO. Sometimes, long drawn out names are used. Likewise, within the code, programmers will duplicate the names. This provides a methodology of flipping from code to GDMO without any ambiguity. One common complaint is the length of the names. Many people will start to model their objects with abbreviations. This is not recommended. Abbreviations are subjective. Likewise, when people read your GDMO subjectiveness creates confusion. Remember too that your GDMO will most likely be read by an international community. What may seem to be an obvious abbreviation to you will not seem so to someone whose native language is not English. Likewise, I try to encourage the same effort of programmers to not abbreviate variable names in the code. If you are too lazy to type it out then you probably should not be doing the work. |
|
Inheritance - The lack of An often overlooked problem in self-developed GDMO is related to inheritance. Very often, the object modeller's inexperience with the standards (X.721, M.3100, etc) results in duplication of effort. What I am referring to here is the definition of managed object classes, attributes, actions, etc which have already been defined in standard documentation. It is a wasted effort to spend time defining things that you could have simply inherited. This problem also does not reveal itself until after the development has started. Primarily because the programmers will be the first ones to take a close look at the object model as they start to write their own code. In the pursuit of smaller application size and dynamic storage requirements the programmer will be the first one to notice that inheritance has not been properly used. The ensuing GDMO changes to correct the inheritance problems will now start to impact the development process. This can easily kill weeks of development time as the development team now has to wait for the re-structuring of the GDMO. Errors within the object definitionsAn almost definite project stopper is errors within the object definitions. Some errors can be detected by GDMO compilers. Many errors related to issues of inheritance and instance naming can not. One can not rely on GDMO compilers to catch ALL of the errors. Also, some compilers are better than others so one compiler may flag an error while another will not. Some compilers will allow partially completed GDMO to be input for on-the-fly syntax checking. Be careful here. |
| Return to Alexandre Polozoff's TMN page Return to Alexandre Polozoff's home page Send mail to Alexandre Polozoff Copyright @ 1995-1998 Alexandre Polozoff. All Rights Reserved. |
|