by Steven J. Owens (unless otherwise attributed)
Q: What's a java bean?
A: Any java object you can pass into the JavaBean Introspector and get back a BeanInfo object for it, which you can use with tools like the BeanBox to interact with the object.
Now the details of how an object can be passed into the Introspector and have a BeanInfo object generated are more complex, but they essentially boil down to following various conventions for getter/setter methods and other aspects of the class, OR to having an appropriate method for generating a custom BeanInfo object.
Q: What's an ENTERPRISE java bean?
A: Any java object that's also a java bean, but beyond that follows a more complex (and narrower) set of conventions that make it compatible with a framework that takes care of a lot of the scaffolding you need to build enterprise class applications.
Q: Then what the heck is an enterprise class application?
A: An ordinary, single-user, application has certain needs and challenges. You start it up, you run it, you do stuff in it, then you shut it down. Tomorrow you do it again.
Next year a new version of the application comes out, you get it, you install it, you maybe import some of your work files into it. Then you get on with your life.
Every now and then you have to deal with somebody who has an older version of the product, so you import some of his/her files into your version, or you export some of your files into their version.
Enterprise applications are used by an organization (i.e. a commercial "enterprise"). They generally don't live that kind of life. They run for long periods of time, serve many users simultaneously, have to run parts on different machines and have to deal with very large scale problems (to the point where the scale changes the nature of the problem), not to mention having to deal with a lot of different problems in the same context - think of Microsoft Office expanded to be used by a whole company at once.
Moving to a new version of the enterprise application is a lot trickier. For one thing, you're a lot less likely to tackle changing the solutions to all of the problems at the same time. For another, you can't just ignore the problem of getting everybody upgraded at once. For yet another, there's a ton of things going on at any given moment in an enterprise system, so you can't just wait until the user isn't using it and install a new version.
Q: What was that about scaffolding?
A: Java has a lot of really nifty, cool stuff built into it, like RMI, reflection, serialization. However, building a complex enterprise application that takes advantage of this nifty stuff is not easy. You end up building a lot of scaffolding on top of it.
For example, RMI takes care of a lot of the low level details of having two java programs communicate with each other across a network. But you have to build a lot of gruntwork code to open the connection, make sure the connection is there, deal with problems when they inevitably happen in the connection, keep track of what part of the program you're dealing with on the other side of the connection, etc.
Not only is this a pain in the ass, it's complicated. Not everybody is good at solving this kind of problem. Not everybody is going to make the same choices in solving the problem. When you do run into another system that somebody built, you're going to have all sorts of problems making them match up.
Can you see where this is leading?