The Author Online Book Forums are Moving

The Author Online Book Forums will soon redirect to Manning's liveBook and liveVideo. All book forum content will migrate to liveBook's discussion forum and all video forum content will migrate to liveVideo. Log in to liveBook or liveVideo with your Manning credentials to join the discussion!

Thank you for your engagement in the AoF over the years! We look forward to offering you a more enhanced forum experience.

lupestro (7) [Avatar] Offline
Hello gentle authors,

I have a certain affinity for making my technology platform decisions as late as I can afford to, preferably after all the difficult code is written. smilie I also like to be able to change my mind or adapt to any situation that arises. I can easily imagine writing a bunch of domain-related business logic that could be reused in a variety of different kinds of applications. Is it feasible to write business logic using JPA entities, entity management, and transactions in such a way that the same business logic can be invoked either inside or outside an EJB container?

I'm thinking that most EJB3 container features don't impact the actual business logic code, just how it behaves as a citizen of a larger society. The features may add a couple of methods of their own (like for state management) or add a few annotations but otherwise it leaves the body of the code alone unless you actually choose to use things like messaging or access to remote beans in the business logic itself. Code designed and written to be thread safe will work as well inside as it will outside the container.

Unlike almost all the rest of these features, the JTA transaction model _is_ closely coupled to JPA and differences in the transaction models force code to be different between them. Is it feasible to code business logic so it will work with either container-managed or application-managed transaction models?

What other big things did I miss? Is what I'm suggesting inherently infeasible or utterly gross to implement in practice? Have any of you tried to do such a thing? If so, what did you discover? Is "EJB3 Lite" light enough to render this whole question irrelevant? smilie

reza_rahman (456) [Avatar] Offline
Re: Dual-use business logic?

You are correct in that the EJB programming model does not influence design/runtime decisions very much. You can use domain driven design with EJB 3.0, which is what I think where you might be headed. Personally, I have tried it and did not like it. Generally, I find the code to be much more muddled as compared to putting business logic is the service tier (EJB 3) as opposed to the domain (JPA entity) tier...

As to running code written for EJB 3 in another another environment (say Spring), it is possible as long as the environment understands how to inject entity managers and manage transactions declaratively (both of which Spring can do). Other than that, you can always create factory methods for retrieving entity managers and transactions yourself and do programmatic transactions (you'll have to do runtime detection in the factory methods yourself). In practice, going to such extremes in the name of re-use is probably overkill.

Lastly, if the only concern here is really being able to run code in Java SE environments as opposed to Java EE environments, you could always use something like OpenEJB which is extremely lightweight and being standardized in EJB 3.1. Finally, if you are concerned about JTA being "heavyweight", that's mostly FUD rooted in awful early implementations of JTA by certain commercial vendors that think every runtime environment is a mainframe. OpenEJB uses JTA in Java SE environments and you can see for yourself that there is no discernible performance difference in execution times as opposed to JDBC transactions.

Hope it helps,