Turning things off

Weigi wrote in a thread at TSS:

"J2EE is too complicated" won't be an excuse to not use J2EE any more because of the modular nature of JBoss's class app servers. Don't like Entity Beans? Simply delete the whole module from the app server!

(not meaning to pick on Weigi, others have and continue to say the same thing. His comment just came to my attention this morning.)

This misses the point, which is that a compatible server can run any J2EE applications (where by "J2EE application" I mean one that depends on portable APIs and not the other stuff) If you disable entity beans, or servlets, or jndi, or whatever, you don't have a compatible server any more. 

If you're lucky, the container will still do the other things you want. But it might not. Who knows? This container configuration wasn't tested. If the container isn't doing other things properly, then your app (that depends on the container contract) may not be either. And we have all seen that application regression test suites are usually not up to the task of fully validating correct (continued) operation of large apps, so you may well not notice that the app isn't doing everything it is supposed to.

Another thing that bugged me about this comments is: why disable <foo> any way? If you don't like to know what day it isn' do you disable your desktop calendar? Or better, the operating system APIs that let your app query the time? If you don't want to use something, don't use it. But don't go futzing with the operating system. Or container, which is after all an operating system for J2EE apps.

Finally, I'm reminded of a blog I wrote in April, about programmers decisions. Perhaps you don't like entity beans, but if so, you're like a carpenter who doesn't like a hammer (he looks pretty stupid trying to drive a nail). Sometimes entity beans aren't the right design choice, so don't use them then. But to say "I don't like them" and go on to rip them out of your system, well, I don't have a family so I'm gonna rip the back seats out of my car to make more room for groceries.

There is a time when it makes sense to turn something off: when you're running a hardened system and haven't security validated some portion of the runtime. I'll note that in such an environment you've probably tested the bejezus out of the total system too, so the downsides of mucking with the OS are mitigated. These guys run a special operating system too.

[Comments from my previous blog]

1. a reader left...

Monday, 19 July 2004 8:12 am

 

JBoss has always (at least as long as I can recall) advertised the ability to remove EJB support. See "Architecture Overview", item 2.
http://www.jboss.org/overview
I don't have an opinion as to whether or not this is a good idea.

Joe Cheng [code@joecheng.com]

2. a reader left...

Monday, 19 July 2004 7:21 pm

 

HOld on, this sounds like complete nonsense. When have you ever written an application and you were not sure whether it used EJB? Or not sure whether it uses JMS??

Foo Bar

3. a reader left...

Tuesday, 20 July 2004 6:57 am

 

One of the great powers of JBoss that many, many users take advantage of is the Microkernel to be able to take out services and build in their own services. J2EE is great, but it does not meet every application's needs. Some need less and some need more. JBoss facilitates this - of course to comply with the Sun J2EE Certification we ship with the whole thing...

Bob
Bob Bickel [bob.bickel@jboss.com]

4. glen martin left...

Tuesday, 20 July 2004 9:35 am

 

Sure, some applications need more features and some less, or in terms of Foo Bar, I know whether I nee EJB or JMS.

The point I was trying to make is that needs change. Our applications live rather longer than we might have imagined, and get extended etc. An application that only does web pages today may develop need for messaging, so a JMS component that was disabled previously would have to be brought back. And in bringing it back, we can (subtly or less so) impact the behaviour of the system that has been there all along because of class conflicts or something.

A value I believe in is that extension should be transparent to the existing system. A number of talks I've done in the past have focused on this. One technique I like is to use async messaging for all iner-coarse-component communications, so I can extend through mere subscription to a message channel. Ie. ESB.

I'll say again, just because one application doesn't use JMS today doesn't mean that JMS should be user-unloaded. By user-unloading, the resulting combination of services is potentially untested. By contrast, an intelligent container might choose whether to load a component or not, and presumably would select between a number of tested runtime configurations, based on the needs of the application(s) currently running.

The result is similar - whether the user disables components or the container does, componets get disabled. But in the case some are promoting, the running container config isn't thoroughly tested. In another it is. One guess which is the better choice.

I'll come back to the example of operating systems. I have one kernel build and one set of drivers I load all the time, I don't change them day to day as my application needs or the network I'm on change. It is a black box. I treat it as one. It provides he servicecs I need today. It will provide the services I need tomorrow without me futzing around with it.