POJOs vs. Entity EJBs

[Tonny Tssagovic]

Hi Guys,
I have an application that requires a connection to an external system to retrieve data. Say "WeatherInfo".
Now, this weather info might be required by different applications, and it is therefore a nice think to be able to access it from different applications. Assuming the WeatherInfo is a POJO (and not an entity bean), how would you do that? WRAP it around a SLSB? Isn�t it too much overhead to have a SLSB just for this single POJO (business object, WeatherInfo)? Package this POJO in a library and use it directly from the library (Hmm, how about connection management and so on).
I do have another question. Would it be appropriate to have a �Business Object� that is no more then a Data structure? (Just like WeatherInfo which has no real functions, responsibilities and is read only data from an external system). Why would you add an extra overhead by adding this Business object (even if it is a POJO), if it is actually just getting a DTO from a DAO, and this DTO is indeed just like the business object POJO? Why wouldn�t you just access this data �WeatherInfo� directly from the WeatherInfoDAO, and add a WeatherInfo POJO that just does that for you ? To decouple the client from the DAO and make it �clean�.
Please advice!!
Thanks a lot!

[Kishore Dandu]

AS much as I would like to look into this posting, it is very difficult to read..
Please paragraphise the complex posts like this.
Dan.

[Tonny Tssagovic]

hmm... I was too tired
Business/domain objects are usually implemented as Entity EJBs. These Entity beans could be looked up, and accessed by different applications.
If one chooses to have a POJO instead of the Entity bean, how would it be possible to access it from different applications.
The second question:
I have a Business Object called "WeatherInfo". This business object represents data (weather data) retreived from an external system (the national weather blah blah system).
- Is this a resonable domain object ? (it only represents data and has no real other functionality)
. This WeatherInfo business object is implemented as a POJO, and uses a DAO pattern to decouple it from the data source (the national weather blah blah system) which could be changed. This DAO has a single function that returns WeatherInfo DATA TRANSFER OBJECT, and the business object WeatherInfo also has one single function that returns weather info.
Is there a problem with this hypot. design?
an extra bonus qquestion. How would you represent this WeatherInfo object in the object or class diagram. Could you represent it with all its DAO and helper classes as a component like an Entity bean component, although they are POJOs..
Well It seems I am adding confusion.. I hope you guys understand what I am trying to say..
Any help will be appreciated. Thanks in advance

[Renat Zubairov]

Hi
Concerning Business/Domain objects.
Sun strictly recomends to use Entity beans for coarse-grained object which need concurent transactional access. The main word here is coarse-grained therefore use it for simple one dimentional objects is waisting of resources. Concecning access in other applications you can see following:
Entity beans with remote inteface - bad thing should be replaced with Session beans + DTO (Value object) at the back end it can be either local Entity or DAO.
Concerning "WeatherInfo" if object is simple, let it be POJO. If it's read only - POJO is only reasonable solution.
You can display it as simpel object with "DAO" and "VO" stereotypes.
Br
Renat
[ March 08, 2004: Message edited by: Renat Zubairov ]

[Chris Mathews]

Originally posted by Renat Zubairov:
Sun strictly recomends to use Entity beans for coarse-grained object which need concurent transactional access.

While Sun may "officially" support Entity Beans, it is interesting that every case study I have seen coming out of Sun in the last two years doesn't use them. For example see these recent case studies: ebay, FETISH Federation, D-reizen, and Brazilian National Health Care. What do they all have in common? They all use plain JDBC instead of Entity Beans. Pretty interesting right?
Personally, as many here know, I avoid Entity Beans like the plague.

[Rufus BugleWeed]

How do you handle concurrency and horizontaly scale with a POJO; leave it to the database?

[john smith]

Access them through a Session Facade. Leave the rest to the DB.

[Chris Mathews]

1) Currency in system transactions is delegated to the database in the case of Entity Beans... why not keep the same approach for POJO? Or are you referring to the fact that Entity Beans are non-reentrant... because that is a limitation not a benefit. Currency in business transactions (which typically span multiple systems transactions and requests) are not handled by EJB so we need to write own implementation anyways.
2) Why... oh why does everybody think that EJB is necessary in order to be scalable!?!?! Excuse me for a minute while I bang my head against the wall...

[Rufus BugleWeed]

While both require a database to control concurrency, JDBC will increase the the amount of coupling to a data base vendor. No? Properly contained in DAOs sure it is overcomeable.
Don't feel like your pounding your head against the wall, feel like you are creating a new recruit. Your distaste for entity beans is troubling and causing reconsideration.
No arguement that scalability is possible w/o entity beans, ejb or j2ee.
I am unconvinced that POJOs don't create a single point of failure in the business domain.
I really like the idea that a skill set is transferable from Weblogic, Websphere to SunOne. Can ORM say the same with Castor, Top-Link and Hibernate?

[Chris Mathews]

Originally posted by Rufus BugleWeed:
While both require a database to control concurrency, JDBC will increase the the amount of coupling to a data base vendor.

Typically when people talk about concurrency and databases they are really referring to isolation levels. Isolation levels are not standardized in the EJB spec and therefore are not portable between Application Servers. Furthermore, isolation levels are supported differently in different database and therefore applications that make use of them (whether using Entity Beans or not) are not necessarily portable between databases even on the same Application Servers. In this regard plain JDBC code is just as portable (or non-portable if you prefer) as using Entity Beans.

Originally posted by Rufus BugleWeed:
I am unconvinced that POJOs don't create a single point of failure in the business domain.

How so?

[Tonny Tssagovic]

Thanks for your replies guys.. Could you please answer my question before continuing your entity beans fight ?
- Does WeatherInfo constitute a "Business Object" even if it merly a data structure. comments?
- Why would I have WeatherInfo business object and not simply retreive it directly from a DAO from my use case controller session bean(that is supposed to use weatherInfo and other business objects to do something usefull)?
Thank you very much for your precious time.

[Jason Stull]

Hi Tonny,
So your POJO is a domain object. It has data, but does it have any behavior? Do you need to apply any business/validation rules when capturing or displaying data?

[Tonny Tssagovic]

Hi Jason,
Yes, my imaginary WeatherInfo is a domain object (implemented as POJO, as most ppl are telling me Entity beans Suck), that represents data retreived from an external system. There is no validation, either the data is valid or an exception is thrown (for example, when a Wrong city param is used to crete the WeatherInfo). I guess that this exception would be trown further up from the DAO to the Business object.
Any clue? And I do actually have 3 external systems with such a Data only behavior, and don't know how to represent them in the class diagram since they r nit "linked" together, and the only objet that has link to them is the use case controller used to retreive data from these 3 systems and use them to please the user.
Awaitng your reply
Thanks in advance.

[Jason Stull]

OK. I'm running in to the same kinds of issues with my DOs. What I'm working on now is a very general way to represent a DO. Now this DO may or may not need all the J2EE features support, TX, persistence, security, etc. I would also like to decouple the DO from J2EE entirely. Meaning that if I have to use Session+EntityBeans for persistence or DAOs, I want this to be transperant to the DO. What if the DO is responsible for all it's behavior, it's persistence, etc., but is able to delegate these aspects to J2EE or other components hiding behind interfaces (and wrappers). In a service oriented way, you could request a DO and have these aspects layered in by the service provider. So your DO has save, validate, etc. functionality without really knowing the details of how it's done (Inversion of Control, kinda). If your DO doesn't need much functionality, then it won't be configured with as much when you request it.
As far as data in/data out. I've been experimenting with using an interface to define what data comes in and out of the DO. So you could have a WeatherInfoImporter interface to bring in data to the DAO and a WeatherInfoExporter interface to send data out of the DO (got this idea from a controversial JavaWorld article). You then call the corresponding import or export methods on the DO. Ex. myWeatherInfo.import(myWeatherInfoImporter) or myWeatherInfo.export(myWeatherInfoExporter). Then maybe later a myWeatherInfo.save(). You could initially have your WeatherInfo object use a DAO for persistence and then later switch to an EntityBean if you wanted without changing the DO at all. Lot of babbling... Does this make sense?

[Tonny Tssagovic]

Thanks for your reply Jason,
I don't know if I fully understood your post, but I certainly understand that one should decouple the DO from the J2ee API/DAO, but I believe having these Importer /Exporter interfaces is overkill for my purpose.
I don't however Understand, how this relates to my initial Post, that is:
- If a "data-structure" with no behaviour WeatherInfo class could be called a Domain Object.
- How would you represent this WeatherInfo in your class Diagram in case they r not linked to any other domain object?
- In case it is just delegating the calls to the DAO, I don't understand what is the purpose of this kind of Domain/Business object? How would it relate to the DAO? How about it's life cycle, Do I need to create this WeatherInfo with the City parameter, and in its constructor it uses the DAO to retrieve and populate its Data structure, and then simply call its GetWeatherInfo, or GetAllDATA function, to later destroy it (it is created and its handle are in the Service Function that is called by the Servlet container to service the end user, so when the weatherInfo is created and given to the user it is Destroyed.) I believe this is too much overhead (AKA creating a Domain Object just to service one request, and this domain object is itself doing nothing but retrieving its data using the DAO, once the client uses it is is destroyed.)
Well I am afraid I will be just adding confusion.
Any help will be very much appreciated.
Thanks in advance.

[Jason Stull]

OK. I'll email you what I'm thinking...