Is it possible to use EJB in architecting a multi-user collaborative application? If so, how might it work, and what are some pitfalls to avoid?

Ron Kurr

EJBs are useful in a variety of situations. If you wish to build your application using components, require transactions, or don't wish to manage some of the basic infrastructure needed for a server (such as thread and connection pooling), then an EJB container may be the way to go.

I think the first step is to decide which EJB spec you want to design against. EJB 1.0 and EJB 1.1 have some differences that you might want to account for in your design. Collaboration implies to me that some database persistence is needed. You'll need to decide if you should use entity beans to fill that role. If you need pub-sub notification or point-to-point message queues, you'll need to verify that the JMS and EJB vendors can operate together transactionally. Although the EJB spec does "gurantee" a certain amount of standarization between vendors, you'll still find differences between containers. You might want to build an abstraction that can help isolate you from those differences. Your build process will also need to account for the different EJB tools that each vendor supplies.

If you are sure that you'll never switch EJB vendors, you can probably ignore the previous advice. If you try to be vendor agnostic, however, be aware of some of the neat things that vendors give you that isn't part of the spec, such as clustering.

If scaling is an issue, try to be as stateless a possible. Using Stateless Session beans is helpful in that area. Finally, your developers must be fully aware that their EJBs will be operating in a multi-threaded environment and code accordingly. Too much synchronization will slow down the system and not enough may corrupt it. Developer education and debugging/analysis tools can help in that area. Threading is hard to get right and it doesn't help that each platform's thread scheduling can behave differently (such as NT vs. Solaris).