I have a question about where to put the container managed transaction within the business tier patterns. For example, chapter 7 of "Core J2EE Patterns" explains the ApplicationService pattern. So, for example you can have:
SLSBFacade->ApplicationService-> DAO or Entity
Chapter 7 has said that an ApplicationService is a POJO. So where is the transaction method? SLSBFacade is too generic to put detailed transaction handling. Should the following be used instead?
SLSBFacade->SLSBApplicationService->ApplicationService-> DAO or Entity
My 2 cents. I would not complicate it that much. I personally think Part2 needed not be overkilled with too many patterns. I would think about putting a custom pattern with a TransactionController which initiates/rolls back transaction and this interacts with SessionBean for all transactional aspects that your system needs. You can differ whether this is the best solution but looking at effort vs benefit, i think this would work fine.
Saha, I am in agreement with you when you proposed
SLSBFacade-->Service/App specific SLSB/SFSB--->pojo-->DAO/Entity. The SFSB facade too generic and will be used by all clients to access the business tier services. Facade in turn delegates to appropriate EJB (SLSB/SFSB). This is how most of the real time projects are implemented.
Joined: Mar 25, 2006
Just to add to my above post, we provide transactional support declaratively to each method of Service/App specific SFSB/SLSB. And this transactional context will be carried to the subsequent components in the call chain like POJO/DAO/Entity beans.
I did not use the term POJO correctly. It should have been any Java class that provides the desired Application Service with value objects (POJOs).
When I said real time, I meant real life projects.
As far as I am aware, J2EE is used for real time projects (I do not mean real critical missions that need very high precision), but general/common commercial applications that need a real time response with a tolerance of about 1-5 secs and where the stakes are not high in case of a failure, but for a slight inconvenience to the user.
Joined: Feb 18, 2006
Yes this is actually true for a commercial user ...who does not care much ...but there are some users to whom it matters like the Stock Brokers ...I do not know of any online stock exchange systems being developed in J2EE..
Slight off board .. but the point is predictability
It is said "A real-time system is one in which the correctness of the computations not only depends upon the logical correctness of the computation but also upon the time at which the result is produced. If the timing constraints of the system are not met, system failure is said to have occurred
Hence, it is essential that the timing constraints of the system are guaranteed to be met. Guaranteeing timing behavior requires that the system be predictable. It is also desirable that the system attain a high degree of utilization while satisfying the timing constraints of the system."
J2EE servers claims to be predictable ..but are they ???
Thank you for the responses. Sorry for getting back to you late.
s khosa - In which component would you put the custom transaction handler as you mentioned? This is good idea, but again, which component contains it? The ApplicationService is defined in Core Patterns as being a POJO...so no transaction there.
The term POJO is plain old java object, as compared with EJB component. A POJO does not have any of the J2EE features: security, transaction, etc.
Joined: May 15, 2003
It would a simple java component using Transaction API. And i would presume any EJB object e.g SessionBean when it has to bill user or update user Mileage account can initiate a transaction using it.
Joined: Feb 23, 2006
Thank you s khosa for the great information. I will ponder this further.
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com