Hi, In your experience with building real-world J2EE-based applications, do you find it practical (or possible to say the least) to place all business logic in EJBs? I find it difficult to imagine an application that completely adheres to this "best practice". There must be some business logic somewhere in the web client that controls the business logic or at least decide which business logic to invoke. Any thoughts?
I am a VERY firm believer in consistency, but I HATE dogmatism. EJB's have enough overhead, that I don't recommend using them as a "one-size-fits-all" solution. On the other hand, if you're looking to make a point-reference implementation of business logic that will be referenced by multiple servers, an EJB might be the best solution, It depends. I know some places who use DBMS stored procedures as for the same general reason.
An IDE is no substitute for an Intelligent Developer.
I agree with Tim. For some deployments, putting the logic in EJBs is better than stored procedures, for others the reverse is true. It really depends on a lot of things: (a) to what extent your app is database driven, (b) whether or not stored procs are expressive enough to capture your business logic requirements, (c) integration with third party systems, (d) level programmer competence with EJB or stored procs, and there are other issues. As a general rule, my belief is that - for performance reasons - if your app is heavily database driven (and especially if the data is highly dynamic), you should push your logic as close to the database as you can get it (i.e., stored procs). Reason being: unless you want to spend your time tweaking an application-level cache, working with data in the database efficiently means working within the address space of the database system software. Databases like Oracle, that are ported to the major OSes, are portable, so as long as your database runs on a given OS, so does the stored procedure. Also, the database folks have spent a lot of time ensuring that the common case use of something like PL/SQL generally interacts fast with the data. On the other hand, if your data is not too dynamic or you do not own the database you integrate with, etc. you might want to use EJBs. They give you better deployment options because they are at a higher level of abstraction. They give you more flexibility in deployment, more modeling options, and potentially more expressivity. I think there are many folks out there using Session EJBs and stored procs (no entity beans). I'm not sure how long that trend will continue or whether it splits the difference in the two approaches. I think it's not a bad idea, but again it depends on the deployment. Hope that helps.
A lot of this argument comes down to the definition of the term "Business Logic". This can encompass many different parts of an application. In general, I find it easier to consider Servlets to be controllers, which manage application flow, which could be viewed as a kind of business logic, but to put my domain-specific business logic (like order management) inside the EJB's. However, as others have pointed out, each project is different and different conditions may apply. A really good reference for understanding the kind of layering decisions that go into this kind of architecture is Martin Fowler's Enterprise Architecture Patterns which covers this in depth. Kyle