hi, Suppose I have two architecture 1.)Stateless Session EJB (A) talking to another Stateless Session EJB (B) , and 2.)Stateless Session EJB (A) talking to a regular java class (C). Lets suppose the logic in B is the same as logic in C. What is lost when moving from architecture 1 to architecture 2? I know Transactional/Security isnt lost; what about clustering? Thanks for the help! Eddie
One thing you lose is the ability to configure your Java class as you would an EJB. For example, if you wanted to do any of the following, you would have trouble:
1) Invoke a Java bean method directly, rather than through your Session EJB.
2) Assign your Java bean method special security or transaction attributes, different from the invoking Session EJB.
Also, you loose object pooling, since your Java object will not (automatically) be pooled and reused. If you are constantly greating and discarding Java objects, you will get some memory churn because of it.
All of these objections are relatively minor, though. The Session-EJB-to-Java-Object architecture is perfectly valid in many cases. This is especially the case because you do not need to use it globally. You can use the more functional Session-EJB-to-Session-EJB calls when you really need them.
As a side note, clustering is generally not a problem with the Session-EJB-to-Java-Object architecture.
Thank you very much!
I think even the transaction is lost.. in the sense that if u would like the tranaction to happen without the dependency on the second java class, then the second architecture would fail..as it would roll back even the first session ejb transactions.. Howeverif you use both the session ejb's then u can have transaction defined at still lower level..i think how u'r business requirements are.I would like to go with the first architecture though
Let me know incase my understanding is incorrect...
The answer to your question depends in part on how you choose to implement object persistence if you decide not to use POJOs (regular java objects) instead of entity beans.
Different persistence tools will allow you to propagate the transaction defined at the Session Bean layer to your POJOs.
Several of the persistence tools also have sophisticated pooling capabilities that work in clustered environments.
You will lose the ability to define object level security on your POJOs. However, if all access to your POJOs comes through the Session Bean layer this is not a significant drawback.
Another thing to consider is ease of testing and the ability to create a domain model adhering to standard object-oriented design practices by using POJOs. With POJOs you can write JUnit tests that run inside your IDE. Entity beans will require a full build and deploy into your EJB container every time you want to run unit tests. This can add a significant amount of time to your development effort. Entity beans also impose limits on how you would otherwise go about designing your domain model (e.g., entity beans do not support inheritance).
If your project is very small, entity beans will probably work fine. For larger projects, I'd definitely recommend Session beans with POJOs for the domain layer.
The trend is to move towards POJOs as a "transparent" way of persistence.
You can grab a JDO book to learn more on POJOs and other mechanisms of persistence rather than using Entity Beans. Entity Beans though, have an advantage of easy access to services offered by the container.