Is "reuse" possible?

Question

Hi,
I am new to EJB, so if I am saying something silly, please forgive me.
I find that reuse of the beans is only possible within a single company, but not across companies, not to mention across industries. It is because within a single company, the environment is more or less the same, especially the database design, then different departments can use the beans as components in their application, thus reuse is possible. However for different companies, there are different environment, database and database design. It is really difficult to develop a bean to fit all the situations.
Yes, it is true that developer can map the bean attributes to the database fields and make the beans workable, but it need much effort and not necessary success. The case can be solved easily for simple application, like a bean requires only to update a single table. However in real world application, things are usually more complicated. Different beans have to interact with each other to get the job done. So I really doubt the beans can really reuse.
Of course I know "plug and play" bean is only a dream, but i really think reuse is not easy, of not possible. In fact I am doing my final year project which is to demontrate the reuse of the EJB. I find it difficult to prove it. Can any experts here explain about the reuse possibility of the EJB to me? I just want to have more ideas on EJB.
Any opinions will be appreciated.

Answer 1

For the majority of the IS and business community, simply getting SOME reuse internally would be greatness -- no need to worry about reuse of the same component at different companies. If you look at how even SMALL development shops still create redundant functionality in separate apps, you realize that reuse has to be PLANNED -- someone has to define those components that should be common to several apps and tell the whole development team that these are going to be developed ONCE and used by everyone. Sort of like a roadmap that can be posted on a wall to show everyone what common components are planned.
In most shops, it is more difficult for new developers to get info on what's available than it is to just develop what you need on your own.
And once you find a class or two you may be able to reuse, you realize that you have to include 20 other classes and packages to get this one to work in the context you want. The answer -- package your reusable functionality as EJBs and not as java classes embedded in a variety of packages.
In our case, we have automated workflows as well as stand-alone applications that both have to access the same provisioning rules. By putting the rules into an EJB component, BOTH types of clients can simply send the "executeRuleX()" message to the component and get the result -- that is reuse. If we decide to perform that same rule check in the GUI, we simply call that same method from a JSP page.
That said, it does not just HAPPEN -- that kind of reuse has to be DESIGNED. Someone has to identify the need for a certain piece of functionality and then develop and deploy it, and then publicize to the whole development team that this ONE component must be used whenever anyone in the business needs to execute that business rule. Not many companies think that hard on what's needed and then consciously document an application architecture that shows these components on the roadmap.
I could go on and on, but you get the idea.
Dave