I have a dynamic web project that consumes fairly complex messages (delivered via a web service) processing the message data on the basis of message type. The application can process fifteen to twenty different message types. There are approximately forty different entity types that are persisted as part of the message processing.
As an alternative, it occurred to me that architecturally each message type could be processed by a separate EJB with one EJB receiving the messages. I assume that one of the concepts behind EJB’s is that they are targeted at a “single” function. Is this correct? Alternatively, how “complex” can the function of an EJB be? Could my entire application sit in a single all purpose EJB.
I guess, these questions are really just philosophical design questions but any comments / advice may help me to develop my understanding of application architecture.
Your question is a little imprecise. There are certain things that an EJB shouldn’t do, such as creating new threads on its own (it has to use the Java EE framework to do that), but essentially EJBs can do whatever you make them do, and they are not necessarily targeted at a single function. There is also no inherent limit on complexity.
Usually, an EJB is designed to perform business logic for a specific area in the application domain. You could make one EJB with multiple methods that each process a message type, or a separate EJB for each message type, or separate EJBs for groups of message types … the options are endless.