Ok, my blog about turning parts of a system (EJB in this case) on and off is nagging at me.
A lot of us like to tinker. And we like to express that tinkering in the form of writing efficient systems. Myself, when I was going through a CS degree, used to pride myself on efficiency. "I can write that in 20% less code and get 10% better performance than anyone is my class."
Obnoxious, eh?
Tinkering gets in the way of productivity and robustness. When Ford designs a new car, they don't usually design a new battery from scratch. Or go to a 16 or 24 volt electrical system (though to do so would definitely solve some sound system problems). They reuse what they have. There is infrastructure that supports 12 volt cars.
Not all car companies work (or have worked) this way. Volvo had the reputation for artisan attention to quality, where a small team built each car from beginning to end, then moved to the next car. Volvo lost.
A lot of folks are worried about success of their company (read: keeping your job), or outsourcing (read: keeping your job). Productivity and "it works" are the way other folks (eg car companies) facing the same issues solved them. They build systems from components that are already designed, and use them as-is.
Dell is another example. Their model is to build systems out of industry-standard components. Unlike some larger companies that designed their own hard-drives, these folks used standard drives already on the shelf. Soooo, how many folks in HP's PC division are still there?
What all this is intended to add up to is: programming is in many respects no different from building other kinds of things. Writing from scratch, or tweaking and chopping and reforming existing components, isn't engineering. Engineering is about reusing existing components whose design properties are understood and proven, and changing only what needs to be changed to solve a problem, so you can predict the outcome (eg. time to market, bug frequency, etc). Repeatable process. The more variables you change, the less you can predict about what you'll get. And the less infrastructure you'll have around to support your product over the full lifecycle of its use.
Monday, July 19, 2004
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.
2. a reader left... 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
Monday, 19 July 2004 7:21 pm
Foo Bar
3. a reader left... 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]
Tuesday, 20 July 2004 6:57 am
Bob
Bob Bickel [bob.bickel@jboss.com]
4. glen martin left... 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.
Tuesday, 20 July 2004 9:35 am
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.
Wednesday, July 14, 2004
Leaving Sun
I've been hesitating to blog on this, but I've have enough queries now that I suppose just to retain my sanity I should just come out and say I've left Sun.
I joined Sun 4 years ago to be product manager for J2EE, which role I had for, oh, about one day, since a number of departures around the time I joined meant I needed to cover some other functions. Since then, I've had the good fortune to meet a lot of really interesting and intelligent people, both in and out of Sun, and work on some really cool things.
If I'm proud of anything, it is that while there I managed to change Sun's licensing model enough to permit open source development of compatible J2EE application servers. It was hard, and really rewarding, and through that process I've done way more about law than I ever imagined (or wished).
But four years is four years, and longer than I'd stayed anywhere for over a decade. Other opportunities called.
In many ways I'll miss Sun. It has been very cool and a great engine of professional growth for me. Maybe I'll go back sometime. I absolutely wish them well, both as a corporation and as a group of individuals I respect.
I joined Sun 4 years ago to be product manager for J2EE, which role I had for, oh, about one day, since a number of departures around the time I joined meant I needed to cover some other functions. Since then, I've had the good fortune to meet a lot of really interesting and intelligent people, both in and out of Sun, and work on some really cool things.
If I'm proud of anything, it is that while there I managed to change Sun's licensing model enough to permit open source development of compatible J2EE application servers. It was hard, and really rewarding, and through that process I've done way more about law than I ever imagined (or wished).
But four years is four years, and longer than I'd stayed anywhere for over a decade. Other opportunities called.
In many ways I'll miss Sun. It has been very cool and a great engine of professional growth for me. Maybe I'll go back sometime. I absolutely wish them well, both as a corporation and as a group of individuals I respect.
1. a reader left... Soo..which company are you going off to? Will you be working with J2EE/Java there also?
Mo
Wednesday, 14 July 2004 8:38 pm
Mo
Subscribe to:
Comments (Atom)
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]