JMX and EJB3 compatibility

[asack]

Can I register an EJB3 with a JMX server and perform custom lifecycle operations on my bean? If so, are there any known limitations or gotchas doing this?

Thanks!

[asack]

Has anyone tried this? :-)! I'm going to attempt tonight but I would really appreciate any input regarding these two technologies and how they relate.

[starksm64]

No, they have no relation. You can create an mbean that interacts with an ejb3 component and visa-versa, but it makes no sense to expose an ejb3 bean via jmx because the lifecycles do not match.

[asack]

No, they have no relation. You can create an mbean that interacts with an ejb3 component and visa-versa, but it makes no sense to expose an ejb3 bean via jmx because the lifecycles do not match.

Scott, first off, thanks for the response. I would like to explore this though a little bit further (hoping you see this!).

I agree that the on face value, the lifecycles don't exactly match but then riddle me this:

What if an EJB3 stateless bean acted like a service (sorta like the custom @Service notation that JBoss provides but not exactly) and I want to instrument this object? Pretend for a moment its possible to start and stop the service as well as other lifecycle management like stuff (not exactly creation and deletion but more like turn on/turn off service flags). I also want to be able to lookup these beans over some sort of domain namespace (granted I could walk through JNDI space but that seems clunky to me, the queryBeans() functionality is what I really want).

I suppose what your getting at is that the lifecycle of an EJB3 object is defined by the EJB3 deployer and that as a developer I have no real control minus the initial lifecycle callbacks defined by the spec (@PostConstruct and friends). i.e defining lifecycle callbacks on a bean via JMX doesn't make sense here. Alright but what if I want my EJB3 to cause notifications to be generated? This seems to be very JMX like and at least to me, not unreasonable.

Maybe the better approach then is to construct a JMX MBean with the EJB3 reference in it so I can get best of both worlds? I can define my own service lifecycle but use EJB3 for the core logic. Is that a bad idea? This design pattern adheres to the separate use of JMX and EJB3. Or is there no synergy whatsoever between JMX and EJB3 (btw, the JMX spec seems to support the claim that a managed object can be an EJB though Scott I will fully concede if this was just spec/theory and not really practical).

Final note, if your going to ask why use EJB3 at all? Well, because I thought it would provide a nice IoC model, allow for state, and is more tightly coupled with other services (persistence comes to mind) than a custom object.

Any feedback would be much appreciated (especially if I'm completely going down the wrong path)! :-)!

[bill.burke]

lifecycle in JMX is a jboss specific addition. Since you already want to use jboss specific extensions, why not @Service?

Add a start/stop method to your @Service's @Management interface and you are ready to go.

[asack]

lifecycle in JMX is a jboss specific addition.

I'm not following...(you mean JBoss Services and their design pattern?)

"bill" wrote:
Since you already want to use jboss specific extensions, why not @Service?

Add a start/stop method to your @Service's @Management interface and you are ready to go.

Well Bill, thanks but the point is I DON'T WANT to use JBoss specific extensions (I admit that this maybe hard) and rather it be a platform agnostic. I really like JBoss but in the end I still want to be platform neutral with my app.

The @Service notation is the right idea (a higher level of abstraction above the EJB3 stuff) but it doesn't quite fit my needs exactly though its close. (why does it have to be a singleton anyway?). I had no idea about the @Management interface but I will assume it allows you to define some lifecycle methods around your @Service object (which seems to me that there is room for custom lifecycle around an EJB).

Can I get something very similar with a @Stateless bean encapsulated by a JMX object? I mean if this was a loose ESB like substance, I suppose notifications and lifecycle management could be done all through custom messages but this isn't what I really want at this stage of the game. I just want to be able to manage properties of an EJB that represents some service (i.e. business domain logic) and provides scale (many clients talking to it).

Again, thanks!

[starksm64]

So wrap an ejb in a jmx service and experiment.

[asack]

Yeah sorry, I'm doing that now as we speak. I don't mean to waste people's time, its just I'm new to both EJB3 and JMX and have some preimplementation nervousness that I'm not on the path to righteousness.

Thanks...hope this turns out right...