Generic Objects Realized Using Software Abstraction


The increasing mix of technologies deployed in enterprise networks places a growing burden on NMS. The software components used to realize NMS must become increasingly abstract. This needs to occur at all levels of the software, with technology specifics cleanly separated in their own layers . So, when application code needs access to NEs via SNMP, all calls should be made to separate code. In other words, business logic should not be mixed with network device technology access code. The simple structure illustrated in Figure 9-3 provides an idea of this demarcation .

Figure 9-3. Demarcation between NMS components.

graphics/09fig03.jpg

All code written to access specific technology should also be as generic as possible; for example, it is better to name a class method ( assuming the code is written in C++ or Java) getLabelValue() than getMPLSLabelValue() because the former can be used for a number of label-based technologies, such as ATM, MPLS, FR, and Pseudo-Wires, whereas the latter is tied to MPLS. In a similar vein, code used to create virtual connections should use naming conventions such as createConnection() rather than createFrameRelayConnection() . The latter is again tied to one technology, whereas the former is more flexible and can be extended to support other technology types as they arise. Parameters in these function calls (or Java methods ) can be used to distinguish the underlying technology types. So, we might have a top-level provisioning code method (with an abbreviated parameter list), such as:

 createConnection(int technologyType, addressType sourceAddr, addressType destAddr, ...) 

Internal to createConnection() , we can distinguish between the technologies using the technologyType parameter. The value of this parameter is then passed to another ( technology-specific ) method that actually creates the required low-level virtual connection using a Java switch statement as follows :

 switch (technologyType) { case (ATM_SPVX) createATMConnection(ATM_SPVX, sourceAddr, destAddr, ...); break; case (FRAME_RELAY_PVX) createFrameRelayConnection (FRAME_RELAY_PVX, sourceAddr, destAddr, ...); break; case (MPLS_LSP) createMPLSConnection (MPLS_LSP, sourceAddr, destAddr, ...); break; case (MPLS_TE_TUNNEL) createMPLSConnection (MPLS_TE_TUNNEL, sourceAddr, destAddr, ...); break; } 

The key point is generic outer code. We get specific about technology only at a well-defined point in the code rather than mix in potentially many different technology types at an early stage. An added bonus of this is that subsequent changes required to one of the low-level methods, such as createMPLSConnection() , do not have any effect on the other methods (such as the ones for Frame Relay or ATM).



Network Management, MIBs and MPLS
Network Management, MIBs and MPLS: Principles, Design and Implementation
ISBN: 0131011138
EAN: 2147483647
Year: 2003
Pages: 150

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net