J2EE - Pattern - Business Objects

[Nithi Rajan]

Dear Friends,

Can you please tell me if the usuage of Business Object in the following sequence is correct?

StatelessSession Bean ----> Business Object ----> Entity ----> EntityManager ----> DB

Basically, I'm confused on Business Object. SUN's Core J2ee Patterns Map says
Business Object implements Entity link -> [http://www.corej2eepatterns.com/Patterns2ndEd/index.htm]

But can I have Entity [as in EJB3] outside Business Object and have the Business Logic
in Business Object. For Example say a method in the StatelessSessionBean needs to
change the Status of two different Entities, can I use Business Object to change the status of
the Entities [like below]?

StatelessSessionBean.endProcess() ----> BusinessObject1.setEntity1StatusClosed() ----> Entity1.setStatus(1)
StatelessSessionBean.endProcess() ---> BusinessObject2.setEntity2StatusClosed() ----> Entity2.setStatus(1)

The StatelessSessionBean will pass the id of Entity1 to BusinessObject1 and the BusinessObject1
will look up for Entity1 in EntityManager and set the status and persist in the DB
And again StatelessSessionBean will pass the id of Entity2 to BusinessObject2 and the BusinessObject2
will look up for Entity2 in EntityManager and set the status and persist in the DB

Is this the correct usuage of Business Object? (i.e) Business Objects are used to perform
certain task on Entities [like changing the status].

OR is the above implementation Wrong in the sense that Business Object are the Entities themselves
and they should implement the Entities. Business Objects cannot be separate from Entities.

Please help me understand Business Objects and what are they used for and where to use them.

Also, kindly let me know if my question is not clear.

Thanks & Regards!
Nithiraj.

[Janis Kazakovs]

In your case, Entity is a Business Object. It encapsulates your business data, which is persisted to a database. So, I would say, simply merge them.

If you want to change the status of two entities you can do this either in Session Facade or Application Service, depending on your design.

[Nithi Rajan]

Janis Kazakovs wrote:In your case, Entity is a Business Object. It encapsulates your business data, which is persisted to a database. So, I would say, simply merge them.

Thanks Janis Kazakovs. The reason I separated Business Object, it looks up the Entity in the Persistance Context, set the value and saves the Entity in the DB. Now, if the merge BO and Entity, then the code for lookup Entity, persist the Entity in DB should be moved to StatelessSessionBean [SessionFacade] , which I dont want. I want StatelessSessionBean [SessionFacade] to be as simple as possible. In that case, what can I use in the case of Business Object in my diagram? Any suggestion?

Janis Kazakovs wrote:If you want to change the status of two entities you can do this either in Session Facade or Application Service, depending on your design.

Thanks again for the valuable suggestion. As I have said earlier, I dont want the code to lookup and persist Entity in the StatelessSessionBean [SessionFacade]. I want StatelessSessionBean [SessionFacade] to be as simple as possible. So, [as you have suggested] can I use Application Service in the place of BO? Is it legal for StatelessSessionBean [SessionFacade] to use Application Service [which inturn lookup and persist Entities] ?

How is the Application Service implemented in J2EE? As a Stateless Session Bean? OR as a Singleton? OR can you thow some light ?

Thanks Janis Kazakovs for your expert advice.

Thanks in advance,
NIthiraj.

[Janis Kazakovs]

Hello Nithiraj,

I assume, that when you mention Entity you mean EJB Entity, from which I conclude that you host your application (or part of it) in EJB container. EJB Entity is persistent domain object, which encapsulates your business data and can be persisted to a storage by means of a persistency framework. In other words, Entity is more technology specific, where Business Object is more business domain specific, since it captures you business requirements, but both of them have the same conceptual meaning.

Now, you wan to decide where to put the logic to retrieve and store your business data. You are right, putting the data access logic in Session Facade wouldn't be a good idea, but you can use Data Access Object to encapsulate that logic and access it from you Session Facade. This is just an example and not advice. You can also follow approach described in Domain Driven Design and use Repository.

With regards to your question about Application Service, I cannot give you a definite answer; it depend on your design. You would like to use Application Service to encapsulate a use case specific logic that operates on several Business Objects. However, the same can be done in Session Facade. Again, it depend on your design decisions.

Application Service, most probably, will be POJO, while Session Facade will be your EJB session bean. Session Facade will call Application Service.

This is one of the possible sequences: SF -> AS -> BO ->DAO

Regards,
Janis

[Nithi Rajan]

Janis Kazakovs wrote:Hello Nithiraj,

I assume, that when you mention Entity you mean EJB Entity, from which I conclude that you host your application (or part of it) in EJB container. EJB Entity is persistent domain object, which encapsulates your business data and can be persisted to a storage by means of a persistency framework. In other words, Entity is more technology specific, where Business Object is more business domain specific, since it captures you business requirements, but both of them have the same conceptual meaning.

Hi Janis,

First of all, thanks a lot for your time. Really appreciate it.
And yes you are correct. By Entity, I mean EJB Entity (as in EJB3).
Thanks for your explanation.

Janis Kazakovs wrote:

Now, you wan to decide where to put the logic to retrieve and store your business data. You are right, putting the data access logic in Session Facade wouldn't be a good idea, but you can use Data Access Object to encapsulate that logic and access it from you Session Facade. This is just an example and not advice. You can also follow approach described in Domain Driven Design and use Repository.

Janis, Please correct me if my following understanding is wrong.

I reason, why I did not consider DAO objects to look up EJB3 Entities and store them back to database is that,
I always thought DAO is used to execute a sql query, get the result set and then assemble a Transfer Object with the values from the Result Set. Please check this link -> http://www.corej2eepatterns.com/Patterns2ndEd/DataAccessObject.htm

But in my case, I'm using EJB3 Entity which is actually mapped to the DB Table and columns. We only need a Persistence Context to load and store these objects from the DB. So, Is DAO an appropriate place to do the look up and storing of EJB3 Entities?

Janis Kazakovs wrote:

With regards to your question about Application Service, I cannot give you a definite answer; it depend on your design. You would like to use Application Service to encapsulate a use case specific logic that operates on several Business Objects. However, the same can be done in Session Facade. Again, it depend on your design decisions.

Application Service, most probably, will be POJO, while Session Facade will be your EJB session bean. Session Facade will call Application Service.

This is one of the possible sequences: SF -> AS -> BO ->DAO

Regards,
Janis

Again, Thanks a lot for your explanation. I would like to have some thing like the following

SF -> ? -> Entity -> Persistence Context [Entity Manager] -> DB

Just confused what should I use in the place of "?"
Using Business Object is ruled out, as Entity [as in EJB3] itself can be considered as a Business Object and look up and store logic cannot go in there.
Using Application Service OR DAO is the other option. But not sure which one is the most appropriate.

[Janis Kazakovs]

Hello Nithiraj,

DAO has nothing to do with the technology you are using, the sole purpose DAO is to encapsulate your data access logic and it doesn't matter whether you use JDBC or JPA. The same as in case with Entity and Business Object, it is not technology centric. It just hides from the rest of the application the data access details. If you have a User entity then you might want to make your application able to findUserByID, find UserByName, fundAllUsers and etc. This is what the code that wants to deal with a User entity should see and this is the functionality you might want to call from, for example, your Session Facade. DAO will call EntityManager in order to retrieve and store User entity. Even if you persist your Entities using JPA you may still write queries, not SQP, but JPQL.

But, please note that DAO is just one of the options. I have already mentioned DDD Repository, you may also decide to put data access logic into the Entity itself, in this case refer to Active Record of Martin Fowler.

With regards to your question about the execution sequence I cannot tell you what to do. You are the architect, you decide! This is the nice part about this assignment. The only think you have to resolve is where to put data access logic. I have mentioned several possibilities, just pick one that you think better suits to your design.

Regards,
Janis

[Nithi Rajan]

Thanks Janis. You have cleared all my doubts.
Really Appreciate it.

Best Regards!
Nithiraj.

[Nithi Rajan]

Hi,

Today i check certmanager website, and I found my Grade was P for Part 3.
So, I assume I passed. [But the score was 0. ]

I would like to take this opportunity to thank Janis Kazakovs who really helped me with his amazing suggestions during Part 2. There are so many architects in this forum and only a few are really willing to help and Janis Kazakovs is one among those kind hearted souls. Thanks buddy for your help.

Regards!

[kri shan]

SF -> ? -> Entity -> Persistence Context [Entity Manager] -> DB

your ? to

SF -> Application Service -> DAO -> Entity -> Persistence Context [Entity Manager] -> DB

[Janis Kazakovs]

Congratulation Nithiraj! I am glad you've made it and that my assistance was of help to you. You probably feel relieved now.

It was a little bit of a surprise for me to see you taking time to say thanks Most of the time people simply silently absorb the help.

Good luck!
Janis