Paul,
Its been awhile since I've done any of this type of programming, but
I don't think it would really require that much interprocess communication.
The ovwdb APIs is what you'd use in the always-running daemon.
The ovw APIs is what you'd usd in the GUI API to update the map,
but you could also use the ovwdb APIs to get/put the actual information
from/to the database. I don't believe there is any restriction on the
ovwdb APIs (in regard to GUI-startup), just the ovw APIs.
The only interprocess communication might be flagging the GUI if the
daemon did an update. This could be done in a number of ways:
a) File Access (have a loop that always checked mod-times)
b) Interprocess Communication
c) Sending/Receiving traps (probably the most NetView-ish way).
All-in-all though, it seems like a lot of what you're doing could be done
through nvsniffer (on NT), and UNIX in the future (assuming they plan on
sync'ing up nvsniffer in a future UNIX version).
That's my 2 cents.
Regards,
Gary Boyles
-----Original Message-----
From: Undetermined origin c/o LISTSERV administrator
[mailto:owner-LISTSERV AT UCSBVM.UCSB DOT EDU]
Sent: Tuesday, August 24, 1999 3:01 AM
To: NV-L AT UCSBVM.UCSB DOT EDU
Subject: Long post: Using Netview APIs to manage network
Hello,
We have been developping a Netview-based network management application,
which basically represents a managed network on a Netview map as a set
of managed nodes each of which in turn is represented as a collection of
hierarchically-organised objects arranged on various submaps. This
allows us to display hard disks, communications cards, running
applications, file systems, etc on separate submaps for each managed
node.
Essentially, the application creates the objects, submaps and symbols
using the OVwDbCreateObject(), OVwCreateSubmap() and OVwCreateSymbol()
API calls. The objects, symbols and submaps are created and deleted in
response to an initial discovery performed when the application starts,
and in response to various traps that can be received by the application
from the nodes being managed. The application is registered in a ARF to
be automatically invoked when the Netview GUI starts.
We now have a new requirement that the OVwDb objects representing the
node objects being managed must always be up-to-date, even when the
Netview GUI is not active. I believe that this involves a complete
redesign of our application into two applications:
- a daemon application that is always active, and which performs the
initial discovery and responds to traps received from managed nodes
- a Netview application that is invoked when the Netview GUI is started,
and which maintains the displayed network topology.
I believe that this involves significant inter-process communication
between the two applications, such that for example, the Netview
application is updated in response to traps received by the daemon
application.
Can anyone help about how best to orgasnise the two applications? The
problem as I see it that the Netview OVwDb objects should be created
and updated by the daemon application, and the submaps and symbols
should be created and updated by the Netview application. But then the
problem is how to determine which symbol to update on which submap?
I suppose that another possibility is to simply have a single daemon
application that only updates objects when Netview is not running, and
which updates objects, symbols and submaps when Netview is active. Is
this a better design approach?
Sorry for the long post. A final question: Is there help available on
how to organise Netview applications? The Programmers' Guide only
concentrates on a description of the available collection of APIs.
Many thanks,
Paul
--
Paul Moore, IBM Global Services
Phone: +32 3 897 2486
Current location: Eurocontrol UAC Maastricht
Phone: +31 43 366 1491
Email: moo AT mas.eurocontrol DOT be
|
