J2EE applicaions architecture...

Question

Hello,
I cannot use CMP because I have very complex queries, and I cannot alter database structure. But I read that BMP are even worse (if you read multiple BMPs, only primary keys are read and afterwards rest data will be read). As I understand. If so it's quite slow.
I don't know what about statless and stateful beans. I am reading about them and trying them now.
But as I understand when I invoke remote method that returns object, object that was returned will be local and cannot use server functionality (I mean directly). For instance in DCOM when object returned its methods will be invoked remotely (if it isn't stated otherwise), I mean I can use server functionality (all objects that cross process boundary will use stub-proxy stuff).
I can use two ways to solve this:
1) I can use Objects with data as a C (language) structs and session beans as functions. This is a funny thing but after everybody sad that C is an extremely uncomfortable technology we returned to a kind of it in Java.
2) I can use wrappers. Client will have wrapper that will hide this by invoking session beans itself. The huge disadvantage is that I have to write a lot of wrappers.
-- I want to hear that do you think about these problems.
-- Can anyone give me some examples of large systems that use J2EE (at least 50-200 concurrent users)?
P.S. I am new to J2EE and quite perplexed with reality after I read so many goot articles about J2EE.
With regards,
Pavel Krupets
Evaluating JBoss/J2EE

Answer 1

Entity beans are meant to be simple, just as objectsare meant to be simple.
I am not against simple objects. But objects ment to
provide data and actions on that data. And some
actions can be performet only at server side. And J2EE
turns objects into structures with get... and set..
methods (EJBs) and functions collections (Session
Beans).Yes, Entities are meant to be a logical layer over the underlying data structure, they provide you security, data integrity acess speed while decoupling the rest of your application from your data base schema. And objects must provide actions since the acton is consistent with the the object, or to be mor strict, with its data, when you use an entity to provide actions that spans all across your application data, you are loosing the meaning of that object.
I'm not saying that you can't have methods other than acessors in your entities, nor i 'am sayng that the acessors must be a direct translation from fields on your data base, just don't miss the point of the them, do not try to smugle business logic into it, entities are logical units that represents the data your sistem uses, as such they function as a facade for your system to view your underlyng DB, if in your A&D you found that some data from your BD have more meaning as an entity, and that same data is found in diferent tables of your system, great!
Just build an entity over views or multiple selects, some day when you decide to change your data base schema, your system will not change, for the sistem views the data through the entities.
If your queries are too complex, they should not be.It's easy to say that, but it's impossible to achive.
Can EJB be stored in multiple tables (some are
optional)? Can EJB load data partly from views
(database contains some tables that store
precalculated data - I cannot omit that)? And I CANNOT
CHANGE database schema.1) Yes, Entities can load from multiple tables and even from no table at all, you can have entities that loads data from legacy sistems or even more mistycal sources.
2) It's never impossible to refactor, and in some cases it's well worthy the effort.
It's a bad thing to say: J2EE will solve all our
problems and we can create database that best suits
EJBs (it's okay with small apps but it's impossible to
achive good performance in enterprise applications).
In my case there is an ordinary database (OLTP) as
well as OLAP. And database schemash are quite complex
(a lot of data stored in db).A loaded data base does not equals to a complex data base schema, and as I said above, the entities function to hide the db schema from the application, so it does not matter if it is complex or not.
A good way to think the beans architeture is to think that the your entities are the interface with the system data, your session are your interface with the outside world..
May the code be with you.