Thanks Thor,
Hmmm, the vexing, often asked question....... Do I JMX or do I JIRO ?? :-)
I can only give you my personal views on this... and hope that the various parties
involved
aren't listening too hard and start beating me up ... :-)
SUN are in a strange position, they are currently supporting three separate and often
competing
management platforms / standards...
JMX - they have a product called JDMK
WBEM - they have a WBEM toolkit
JIRO - they seem to be hot on this one at the moment... :-)
could make them mucho money, I guess :-)
It is interesting to note that at JavaOne this year, there were about 8 sessions on
Jiro
and only one on JMX and none on WBEM... Not sure what this says.... ;-)
My view...
Jiro is not a standard, it is a SUN product, and it is fairly heavy weight.
It is trying to be all things to all people, it is more of a management framework
than a method of instrumenting java code. Look at Jiro if you want to implement
a big management system... Jiro is supposed to work with JMX and WBEM.
It is supposed to sit on top of these interface layers and provide management
services... That is what it is good at... Also remember that while they tout it as
being a very generic framework, it is really only being used in the storage management
world at the moment (this is what it was originally designed to do).
JMX is the way to get at the information... so from the point of view of J2EE
management,
Jiro is not that relevent.. all you need is a way to get at the information and the
definition of the information you can get at... Jiro is way too big (and expensive :-)
to be used for this purpose....
Does that make sense ?
--Geoff
>
>------------------------------------------------------------------------------------------------------------------------
>
> Subject: Re: Vendors supporting CMI (Console Management Interface) API?
> Date: Tue, 19 Sep 2000 15:09:06 -0700
> From: Thor Heinrichs-Wolpert <[EMAIL PROTECTED]>
> Reply-To: A mailing list for Enterprise JavaBeans development
> <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> References: <[EMAIL PROTECTED]>
>
> 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".
===========================================================================
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".
