JavaWorld has published an article entitled "Manage your JMX-enabled applications with jManage 1.0" which introduces readers to the jManage 1.0 features using J2SE platform MBeans as examples. This is a good read for anyone looking to understand jManage 1.0 features. It also shows what J2SE 5.0 MBeans have to offer.

In the past, you might have used log files to figure your application's runtime behavior. Or you might have written custom management interfaces to get runtime information, perform runtime administrative operations, or for sending alerts when something goes wrong. JMX makes it easy to instrument applications using MBeans, Java objects that represent manageable resources. With MBeans, JMX-enabled applications can be managed and monitored using JMX clients.

jManage is an open source, Web and command line-based JMX client that has been built based on the real needs of production environments. It offers a centralized console for managing application clusters and distributed-application environments. The tool also provides alerts, graphs, security, SNMP (Simple Network Management Protocol) support, and fine-grained access control. jManage supports custom remoting protocols for Weblogic 6+, JBoss 3.2+, Websphere 5+, along with the standard JMX Remote API protocol (Java Specification Request (JSR) 160).

Along with the upcoming jManage features listed in this article, jManage community maintains an online roadmap for future features.

Do you think jManage is headed in the right direction?

It is not very clear who is considered to be the target audience for this product.

For example, working with WebSphere, developers happily use its native web console or JACL/Jython for "batch" scripting.

And if you need to appeal to these less WebSphere-savvy application administrators (or whatever you call them), you'd need something more simple and polished, tailored to specific applications and maintenance tasks, rather than an awful raw JMX web-interface. One might think of building something on top of JACL/Jython or a webapp - custom JMX client.

So what's the need for another generic management layer?

It is not very clear who is considered to be the target audience for this product.

The target audience is operations team, QA and developers. Operations team usually retains complete access and QA/developers have limited access.

For example, working with WebSphere, developers happily use its native web console or JACL/Jython for "batch" scripting.

I am not familiar with what WebSphere has to offer, but I have seen a clear need for a tool like jManage, while working with Weblogic and JBoss.

jManage's goal is to provide a centralized console for management of production environment, i.e., to go beyond application servers by including monitoring of databases, operating systems, etc. I am sure WebSphere's doesn't solve this problem.

jManage also solves the problem of fine-grained access control and cluster management. Does WebSphere provide anything for cluster level management?

tailored to specific applications and maintenance tasks

1.5 release will include dashboards, which will fix this problem.

Operations team usually retains complete access and QA/developers have limited access.

Please note that I was referring to a production environment. In a QA environment, QA and Developers may have full access.

jManage provides fine-grained access control via acl-config.properties. See the following for more information:
http://www.jmanage.org/documentation/jmanage0.5/accessControl.html#Fine-grained+Access+Control

Operations team usually retains complete access and QA/developers have limited access.

Please note that I was referring to a production environment. In a QA environment, QA and Developers may have full access.jManage provides fine-grained access control via acl-config.properties. See the following for more information:http://www.jmanage.org/documentation/jmanage0.5/accessControl.html#Fine-grained+Access+Control

IBM rely on their tivoli product to manage the network, apps etc. However, I do see a need for this product since most of the monitoring applications don't support JMX for different J2EE servers.

dino

It is not very clear who is considered to be the target audience for this product.For example, working with WebSphere, developers happily use its native web console or JACL/Jython for "batch" scripting.And if you need to appeal to these less WebSphere-savvy application administrators (or whatever you call them), you'd need something more simple and polished, tailored to specific applications and maintenance tasks, rather than an awful raw JMX web-interface. One might think of building something on top of JACL/Jython or a webapp - custom JMX client.So what's the need for another generic management layer?

How about everyone who needs an HTML JMX console but is not using WebSphere, WebLogic, or JBoss (or paying for Sun's HTML JMX console)?

There is no need for a application server for many business cases. There is also no need for one just to use JMX and thanks to jManage there is no need for an application server or to buy any software just to get a decent HTML JMX console.

http://www.jmanage.org

jManage is successfully being used by various companies, in Development, QA, Staging and Production environments.

Does Bhavana want to tell us who the current clients are?

We're interested in knowing jManage's client list. Thank you for a good product - the product can only get better with more and more feedback.

Timur Evdokimov in this thread says "an awful raw JMX web-interface". That should only be a motivating factor. Don't ignore Timur. Timur believes destruction works better than construction on this planet.

We're interested in knowing jManage's client list.

jManage is a open source community. I am not sure if there are any legal issues in listing the companies that use jmanage. I assume that we will have to get permission from the listed companies.

If someone reading this thread uses jManage, please respond.

Hi,

The previous poster was right about the current state of most JMX UI's but much too harsh on the jManage UI itself.

The problem I see with JMX management consoles is that the interface is largely a straight forward rendering of the bean and attributes themselves. I do not think the original architects of the management (and monitoring) API envisaged users have such a raw interface to the beans. It was probably expected that tool vendors would invest significant energy and resources in delivering management consoles with insightful visualizations and context awareness. Sadly this is not the case and most management console treat all MBeans generically - not translating operations and attributes into high level goals delivered via contextual processes, tasks and visualizations.

With regard to the monitoring aspect of JMX we have enhancements readied for JXInsight 4.1 (mid feb 2006 release) which integrate JMX defined/derived metrics within our timeline, metric and profile analysis modes. Java 5 management metrics have already been delivered in an early access build. JMX defined metrics will appear alongside JXInsight's own JVM profiling, tracing and resource transaction monitoring metrics.
http://www.jinspired.com/products/jdbinsight/tracegroupmetrics.html
http://www.jinspired.com/products/jdbinsight/downloads/new-in-3.0.html


regards,

William Louth
JXInsight Product Architect
JInspired

"J*EE tuning, testing and tracing with JXInsight"
http://www.jinspired.com

http://www.jroller.org/page/wlouth

It was probably expected that tool vendors would invest significant energy and resources in delivering management consoles with insightful visualizations and context awareness. Sadly this is not the case and most management console treat all MBeans generically - not translating operations and attributes into high level goals delivered via contextual processes, tasks and visualizations.

This is exactly what jManage dashboards plan to address. This feature is planned to be released in the second quarter of 2006, as part of jManage 1.5.

The dashboards framework will allow jManage users to either use an existing dashboard or to create their own. A new dashboard can be contributed back to the community, for other users to download and use.

Timur Evdokimov in this thread says "an awful raw JMX web-interface". That should only be a motivating factor. Don't ignore Timur. Timur believes destruction works better than construction on this planet.

Ha-ha-ha! If only you knew how right you are about him!

2Timur: not everyone on this planet is out of luck being stuck with WebSphere.

To start with, I wasn't particularly speaking about WebSphere. The point is that the application developers who are smart enough to work with complex interfaces such as native appserver console or pure JMX access to control application and server using beans, currently are priced at EUR 80..120/hr in the part of the world where I'm happen to work now.

Because of that, in all large IT environments, the application, once developed and entered the maintenance cycle, is always taken over by someone who's less ambitious and therefore substantially cheaper. These people, once provided with straightforward work instructions and interfaces which are not cluttered with unnecessary technical info, are able to control the servers and applications at much lower cost.

Indeed if you are happy enought to be sole analyst and architect and developer and maintainer of a small enough application, it's a waste of time investing your time into any sort of management interface.

My point seem to be taken by Rakesh, so I'm looking forward for these 'dashboards'. If this is sort of generic framework for simplified management interfaces, it will become interesting for those working for big IT shops.

Above all, I think Ed could find better places than this website to exchange personal attacks.
So I won't continue on that.

Sorry didn't wake up completely yet

...enought...==...enough...
...waste of time investing your time into...==waste of time investing...

I think this is a good idea. We've designed the ObjectGrid to work with external management consoles such as Advent Net or MC4J and I'd imagine it'd work fine with this also. I think the last thing customers want is a seperate console for each piece of middleware in the solution. So, we chose instead to provide a standard JMX interface. If it can attach using MX4J or J2SE 1.5 JMX then it should just work.

Billy
(IBM)
http://www.devwebsphere.com

I think the last thing customers want is a seperate console for each piece of middleware in the solution. So, we chose instead to provide a standard JMX interface.

what about PMI vs. JMX? will IBM continue supporting both and if so, can you comment on the +s and -s of both (w.r.t websphere of course)?

PMI is here to stay as it's a supported programming model and so we'd need to give customers 3 years notice if that changed.

ObjectGrid supports both PMI and JMX for obtaining performance stats. We need to since we're not dependant on the runtime. This has the side effect of making things much easier to get at from a third party monitor like AdventNet or MC4J and hopefully JManage.

I'm actually not sure if everything in PMI is accessible using JMX or not. I know PMI does use complex types for the attributes which complicates things for third party monitors. ObjectGrid attributes are always scalars to avoid this issue and thus allow any monitor that can use MX4J or J2SE 1.5 JMX to attach to us with no additional jars etc.

Billy (IBM)
Check out my LAMP experiment @ http://www.trackpedia.com

Please note that the support for WebSphere is broken in 1.0.1 release. This has been fixed in the upcoming 1.0.2 release. See Bug# 1407534 for the details on the fix.

There are also UI improvements in 1.0.2, to better display the long MBean names used by WebSphere.

Note that 1.0.2 has been released.