After spending some time talking with customers at CA World, I've realized that not everyone gets the vision of a unified object model. The other observation is that even though QR codes are everywhere (and I mean everywhere people, open your eyes!), half of the self proclaimed "techies" out there have no clue what a QR code is. To continue with this tangent, I can't wait until we have 3D detectors on our phones and can keep them in our pockets. Along the same line, just wait until a phone in your pocket can pickup and store the information encoded in 3D QR codes you pass by every day. But I digress.
A unified object model is a method of designing systems so that they all have a concept of the types of data objects with which they will all interact. For example, gohastings.com knows what a DVD is. When I search, I can search for just DVD's or I can include books and video games. This is a simple example, but the fundamentals are the same.
As for network monitoring software, it is essential that any user interaction interface know about the different types of objects contained there. It is my understanding that this is one of the main goals of the Catalyst project at CA. Before anyone out there begins to argue, I'm not saying that this is the most technically direct definition. I'm trying to boil it down.
NPC actually already utilized a somewhat unified object model, implementing a concept called context. Context is refers to the object of focus of a control or page. For example, one type of context in NPC is the interface context. The interface context allows NPC to understand what an interface is and what products report data pertaining to interfaces. ReporterAnalyzer (aka NFA), eHealth, and NetVoyant all deliver interface based statistics. Since NPC knows what an interface is due to the object model implemented, it can deliver a mix of information from all three products. The object model in NPC has its limitations, however CA has promised to expand that model (Catalyst).
For me, some of the most important contexts are group, site, application, server, router, switch, generic IP based device, interface, CPU, and memory, among others. While it would be good to have a complete list of all the basic and intermediately complex contexts, what is most important is that context be extensible.
NetVoyant actually accomplished this in part due to the nature of the self certification process. While top level contexts were fixed (group, router, switch, server), the child objects could be extended by building a new certification. The advantage of this is that NetVoyant knew about every different type of child object. Whether it was a temperature probe, a UPS battery, or a server case intrusion detection switch. Also, every context had its own set of pages. Which meant that when I drill into a battery, I always see battery related data. When I drill into an interface, I always see the same interface report with the same layout, with the same types of graphs. The only difference was the object focused on.
One of the limitations of the NetVoyant object model was that it only partially allowed for different types of devices. While drilling into a server, a switch, or a router took me to their individually designed and tailored pages, any other type of device (firewall, WAP, wan accelerator, et al) would always take me to the same set of 'generic device' pages.
To some extent, this is the point of a unified object model. Implementing the knowledge of how objects interact with each other and what kind of data is associated with each type of object. Along with this, Catalyst seeks to unify how systems interact with each other when requesting information about each type of data. By unifying and classifying this data and standardizing how the data is shared, more integrations can be made with less effort. And that's the whole point of a unified object model.
No comments:
Post a Comment