Ejb Architecture Roles

The specification of EnterpriseJavaBeans defines the following EjbArchitectureRoles:

A question: how many people have ever "assembled" an application from enterprise beans provided by various providers? I haven't done any of that on my last five EJB projects, and I don't think I ever will. To me those two roles do not necessarily reflect how systems are really built. --RandyStafford

The roles to me refer to how I'm working: When I'm coding the beans, I'm wearing my BeanProvider? hat. When I'm put the application together, I'm wearing my ApplicationAssembler? hat. Whether all of the beans were written in house or not doesn't really matter (except when it comes time to fix the bugs!). Maybe I've bought some of them, maybe I wrote some of them for an earlier project, or maybe I wrote all of them a few minutes ago. I still have the task of putting them all together to be used. In addition, when it comes to co-ordinating a team, you'll should really only have one person tinkering with the application assembly at a time.

The defined roles provide a mental model worth thinking about. Unfortunately, they can also lead to pool tool usability. For example, consider the WebSphere "Application Assembly Tool". It could be considered an implementation of exactly what a person would need, in the "Application Assembler" role. It is also an example of highly needless (and nearly endless) tedium for actual use on a project of any size. (Many teams end up ignoring and figuring out how to do that from the command line as part of a build process, happily.)

Your rant about not finding EJB deployers and application assemblers is mostly true in the development world. I have never worked with an integration manager, we always used Cruise Control, LuntBuild, Continuum and the like. Now I'm working side by side with an integration manager. He creates all the branches and merges all the branches. You need to send him an email everytime you need to create a branch or merge it. What a waste of resources for something that could be automated using Jira or the like.

If there is a role and nobody is 100% of the time assigned to it, the process can be smoother or it can be worse. It all depends on the expectations and the problems found along the way. Probably Cruise Control would be unnecessary if we had a more strict process (for example having running maven before a check-in). But I've never seen such a process.

EditText of this page (last edited December 11, 2007) or FindPage with title or text search