Let's start with some additional thoughts. Remember: I liked to have
acces to a wide range of resources to obtain management information
(from local files to database systems). I think the acces must not
necessarily go via a management server but could also be available at
the client level. Some of the information is user dependent, think of
user interface customization like with X resources (do you like an
problem be shown by an endless flashing icon, or is 20 flashes and
then changing the colour to red enough? Maybe you also want to have
some beeps or to deiconify tkined?). Other information is available
on every system or available by other protocols, like ip addresses
(file, NIS, DNS). So maybe there should be an abstraction of the
access possibilities, so tkined implementation is not concerned with
implementation, wether it is CORBA based, SNMP, ONC RPC, local file,
... Ok you (answer addressed not only to J=FCrgen, but also to others)
don't like "abstractions without code", but for this issue it is
really useful!
I wonder why there is no such abstraction upto now? We have ined
objects with attributes. Eg. one attribute is "SNMP:Config" which has
subattributes (community, writecommunit, port, ...). Why isn't the
attribute space flat, having attributes like "SNMP_community",
"SNMP_writecommunity", ...? (I don't think hierarchically namespaces
to be bad, but it seems to me, that the attribute list can be
extended on demand on the GUI level, while extension of the
subattributes of "SNMP:Config" needs reprogramming of TCL scripts or
even C code. Suppose you want to introduce a "trap community"? If set
as normal attribute, it could be used by only changing some tcl code?
(Am I wrong? Maybe I did not learn enough about tkined and tcl/tk upto
now, forgive me).
Juergen Schoenwaelder wrote:
>[ Well, you brought up the CORBA topic so I will shoot now. ;-) ]
>
>I have read papers and heard even more talks about the use of CORBA
>for network management or systems management, how to map from ISO,
>IETF, DMTF management to CORBA and back and so forth. But I never saw
>an implementation which is small, understandable, portable,
>interoperable with third party products and highly adaptable to side
>specific needs.
One main reason for me to propose a platform was that I do not like
thinking about protocols (which is interesting of course, but not at
this point). I want to concentrate on the application code, which is
easy to embedd in a CORBA skeleton. On a socket based environment we
have to build some abstractions to easily manage communication. I
assume for a client server based system communication will mostly have
RPC semantics. Why should we reinvent the wheel? Another point is
"marshalling" which is done by CORBA and needs not be done by us.
>The last point is very important for me: Our networks and our (UNIX)
>systems usually look very different from site to site - a result of
>the open market. (Windows environments don't have this huge number of
>differences that UNIX environments have.) Hence I consider it very
>important to build a system that invites people to make modifications
>and enhancements. Scripting is one way to get this flexibility. CORBA
>does not help here.
Scripting helps on programming language level, CORBA on communication
level.
>Why does object-orientation help to solve the problem? Yes, I know the
>benefits of object-orientation. But are these benefits critical for
>successful system or network management or just an implementation
>issue? (You should not mention it as the first argument if its an
>implementation issue.)
(The arguments have not been priority orderd).
Object orientation in communication helps to cope with different
instances of the same type (or class :-). With other protocol
mechanisms we have to handle the different instances by ourselves,
eg. in ONC RPC normaly there is only one instance of an object on
every host.
>But nevertheless not generally available and I have mixed expectations
>about their interoperability/efficiency.
I didn't investigate ILU or Electra upto now. Maybe the efficiency of
CORBA will much worse than socket communications. I agree with your
doubts in this point.
>Many organizations consider some technology important at some point in
>time and a few years later something completely different has taken
>over the whole scene. Do you remember what people and organizations
>told us about DME a few years ago?
Yes, this should be kept in mind!
>Lets assume that JAVA is important. This does not automatically make
>everything an important agent platform that has a JAVA interface.
Well, I see some benefits with JAVA (portable, independent, object
oriented, will maybe become widely accepted, ...) which will not help
for our discussion here (some of it is also true for tcl). Maybe one
point: Students want to write their "master thesis" in JAVA, to learn
it and have a good opportunity in finding a job. Some of my work is
based or will be based on student's thesis work ... ;-) Hopefully I
can convince them to learn tcl/tk instead and "sell" themselves as
"experts in scripting languages" on the job market.
>I am not going to make use of CORBA or any other package which is not
>easily available on the average UNIX (or NT?) system. I believe in
>small systems and evolution. Tkined surely needs an evolutionary step
>to increase its usefulness. But it will be just a step forward and not
>an attempt to build the overall management solution. (Many people have
>tried to build the overall management solution in the past and many of
>these projects simply fail to deliver what they have promised.)
>
>I know that the European research community really loves to talk about
>thinks like CORBA, TINA, DCE, TNM, ODP, ... but this is far away from
>my everyday world. You should take a critical look at these things and
>come up with your own mind how useful and/or successful these
>technologies are to solve our everyday management problems and why we
>still use utilities based on other technologies to get our work done.
You're right with the small systems. I also like them better and
think evolution is done in small steps. I also fear to rely on
"foreign" technology which may be successful or not or even be dead in
some years.
Let's resume: I proposed to use CORBA since it covers the
communication problems and has the some benefits (easily handling
multiple instances, which seems to be important to me, no problems
with marshalling, ...). But I am not absolutely bound to CORBA, there
will be other mechanisms to access a management repository (which is
my main research interest). Maybe the interfaces can be designed to
allow for an open architecture with communications based on different
paradigms (sockets, RPCs, CORBA,
...).=20
Cheers,
--=20
Gerd Aschemann --- aschemann@Informatik.TH-Darmstadt.de
Ver=F6ffentlichen hei=DFt Ver=E4ndern (Carmen Thomas)