Great reply!
But how does JMX and JIRO fit together, or not as the case may be.  Which
would be a better candidate?

Thor HW
----- Original Message -----
From: "Geoff Bullen" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, September 19, 2000 3:29 PM
Subject: Re: Vendors supporting CMI (Console Management Interface) API?


> Curt,
> you bring up some very good and valid points.  Let me try to address some
of these issues and
> point you towards some answers and other potential sources of information.
>
> Areas of Management
> If we are going to provide a management solution for EJB (and any other
area) we need two
> things :
> 1) A Standard way to access components and manipulate data, execute
methods and get events.
>     In the network management world this is provided by SNMP.
> 2) A Standard, defined model for the component that you are trying to
manage.
>     In the network management world this is like MIB2.
> Point 1 provides you with an interface to get at stuff, point 2 provides
you with what
> you can do when you get there...  Without both of these things you don't
have a story.
>
> Why SNMP is not a good solution
> Many people think that SNMP is that answer to all management needs, and
why don't we
> just use it for managing distributed applications as well...
> Personally I see this as a very bad idea, and here's my reasoning, blow me
up if you like...
> The basic premise behind SNMP is the MIB, which is sort of like a
distributed database.
> Each network host has its bit of the data, and the managemnt system
interrogates each bit
> (using SNMP) as necessay to provide uniform management.  So far, so good.
> Now it seems to me that one of the basic characteristics of a distributed
application is that
> it runs on many hosts, that, in fact, it may run ondifferent hosts
tomorrow than it did today,
> due to fail over, load balancing, etc....  So, my contention is that a
distributed application
> does not run on a host, it runs on a network, OK ?
> So now let's try to manage my distributed application using SNMP.
> Now this distributed database of MIBs actually has a primary key.  What is
it.
> Well, its the IP address of the host.  Without that you don't get
anywhere.
> OK, so if a distributed application runs on a network and not a computer,
then it
> has no IP address, nor do its components.
> So in order to manage a distributed application using SNMP I basically
loose
> the primary key of the database, the basic premise behind the management
paradigm....
> Mmmmmmmmm...
> To me everything from then on is just a complete fudge to make it work....
>
> What's currently happening in J2EE management ?
> Things are improving in terms of management and J2EE.....
> In the first spec, management was mentioned as part of one sentence buried
deep
> in some forgotten paragraph.
> In the 1.2 spec, management has an entire sentence devoted to it,
> buried deep in some forgotten paragraph :-)
> What this has meant is that every Application Server vendor has
implemented their
> own solution - all of them bad... Why ?  Because they don't know anything
about the
> management space, they know about Application Servers.  So their consoles
tend
> to be configuration consoles, not runtime operation consoles - big
difference !!
> Anyway, the people who do know about such things, Tivoli, CA, BMC, etc...
can't
> manage this stuff because mostly the App Server vendors don't even provide
an
> external management interface, so they couldn't even if they wanted too.
> Also these companies tend to do system management, manage processes and
groups of
> processes.  It can be hard for them to start managing objects and
applications that
> can contain all sorts of stuff like dependency relationships, etc...
>
> My pesonal opinion is that you can't expect the Application Server Vendors
to do
> the right thing, the best way is to make it so that the real management
players can
> have access to the information they need.
>
> But fear not, the world is slowly changing !!!!
>
> There are three, yes, count them, three, standards bodies currently
commited to
> changing and correcting this problem.  (sorry if I missed anybody out :-)
>
> SUN Community Process - JMX (java.sun.com/products/JavaManagement)
> This group is about defining the SNMP part of the picture, at least for
Java.
> It is defining the infrastructure that will allow management systems to
talk to
> managed components.  A competing standard here is WBEM.
>
> SUN Community Process - J2EE Management - the famous Group 77
>
(java.sun.com/aboutJava/communityprocess/jsr/jsr_077_management.html)
> This group has just been formed, and will finally define some management
that will
> go into the J2EE spec, version 1.3.  This group has not yet met, so it is
hard to say
> what will happen, but I hope that they will adopt JMX and then put some
kind of
> model on top so that we have both the SNMP and the MIB2 parts to the
puzzle.
> This way management vendors canthen provide generic solutions for managing
this
> space.
>
> DMTF - Application Modelling Group (www.dmtf.org)
> This group is busy working on a general model for the runtime aspects of
a distributed
> application.  It is hard and slow work, but it is progressing.  I hope
that some of this
> work may be used by the J2EE group...
>
> Where you can help ?
> Curt, I would love you to either get involved in some of these standards
bodies yourself, or
> at least to email me with your Operation's Center's use cases, so that we
can make sure
> that these issues are covered by the standards we propose.  I am aware of
some of the
> problems, but I can sure use some help :-)
> I currently strain by being a part of all three of these groups... :-)
>
> Best regards,
> Geoff Bullen
>
>
===========================================================================
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body
> of the message "signoff EJB-INTEREST".  For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
>
>

===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST".  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".

Reply via email to