• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

General Architect Question

 
Greenhorn
Posts: 21
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,
If you as the designer which approach do you
prefer :
1. Has more components in your design,
where these components can be EJBs and
these EJBs are used in proper way
(there is a need for transaction, and
etc).
2. Has less components, if it's possible
put everything in one big session facade
and this session facade delegates it
to another simply Java Codes (not an EJB).
In other way if possible only 1 EJB for subsystem.
If you choose the 1st approach then what
is the reason and also the 2nd one.
Best regards,
Alex
 
Ranch Hand
Posts: 2713
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Basically, this depends entirely on the specifics of your project. In general, I like to keep down complexity whenever possible. However, if you are dealing with multiple teams of developers on a large project then you will be forced to increase complexity just to manage dependencies.
Dependencies == Bad.
Ask a general question; expect a general answer.
 
Ranch Hand
Posts: 72
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
That question causes headaches. As an architect you have to make (again ) trade-offs between choosing entity beans or plain java objects for business model, and this is the question you asked, isn't it?
Here is my point of view: If you use entity beans you need not code transaction control (CMT), OR-Mapping (CMP), security and scalability (pooling of instances/shared access) issues. The ejb container provides these services for you. Container which implements the EJB 2.0 spec provide CMP engines which provide some optimizations behind the scenes (lazy/aggressive loading, n+1 read problem, bulk updates and dirty flag strategy). If you use plain java objects you either has to code the database access functions on your own (and this can be very tricky, especially if you want to implement some optimizations as described above) or you use a (commercial) OR-Mapping tool (TopLink, Castor, ....) which comes with some costs.
The EJB 2.0 spec supports only one-to-one object-to-table mapping. Some vendors here provide proprietary features (deployment descriptor) to map one object to multiple tables. But if you use your own DB-wrapper (plain java objcts and JDBC or EJB + BMP) you are free to map objects to tables.
What's about scalability: Entity EJB instances can be pooled, so they provide shared access. If many concurrent clients requests an entity bean, passivation/activation takes place. This leads to high disk I/O and the performance will suffer. If you use plain java objects you will have many instantiations (one for each client). Probaply you have to build a prototype to evaluate the performance/scalability requirements.
It is also a question of the present skills in the development team. If there are no EJB specialists plain java objects is the choice.
If you use entity beans, use only local entity beans for your business objects, wrapped by a remote session bean facade. IF you use plain java objects as business objests use also a remote session bean facade, which controls the transactions (CMT/BMT).
Now, what is the answer ? It depends ! Using plain java objects is a legitim choice. But if you use them then use a well established OR-Mapping tool like TopLink and a session facade for transaction and security control.
And what about JDO instead of entity beans ?
Thomas
 
Alex John
Greenhorn
Posts: 21
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thank you for the GREAT replies
In the answer about keeping the complexity down then using one big / fat session facade can keep the complexity down since clients only know one facade rather than many beans.
But since the components which the facade hides/delegates are not EJB and they are simply plain java codes then other tiers like web tiers cannot use it directly in instance it only needs it (not the facade, if web tiers use it directly
then there is no good separation between these tiers) and maybe some components needs to be moved to another subsystem then we have to again change the facade and the clients.
This can be happened in the project that is not mature yet.. Thinking of this, maybe having more separated components is better approach in term of flexibility (but performance problem may occur)...
In the examples of my question, I assume the plain java has transaction / security control from its facade so there is no need to use other party tools.
About Entity Beans, I heard many people suggest avoiding that since some application servers really have poor performance to handle it, and it is right as in the reply that it causes nightmare for performance due to activation/passivation/load/store of the bean. You are right; maybe JDO is better than Entity Beans.
But comes another question again, that in the design for part II (without JDO), how we really know when to use Entity beans (due to bad performance of Entity beans?)
Thank you for the reply..
[ February 20, 2003: Message edited by: Alex John ]
 
Thomas Hofmann
Ranch Hand
Posts: 72
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
First of all: You should always use a session facade regardless of the use of plain java objects or entity beans.


In the examples of my question, I assume the plain java has transaction / security control from its facade so there is no need to use other party tools.


The facade should always control the transactions. If you use 3rd party tools: I meant OR-Mapping tools to map the objects to the tables, not for controlling transactions.

n the answer about keeping the complexity down then using one big / fat session facade can keep the complexity down since clients only know one facade rather than many beans.


That is the reason why you should use a facade, but also in the case of (local) entity beans as business objects.

But since the components which the facade hides/delegates are not EJB and they are simply plain java codes then other tiers like web tiers cannot use it directly in instance it only needs it (not the facade, if web tiers use it directly
then there is no good separation between these tiers) and maybe some components needs to be moved to another subsystem then we have to again change the facade and the clients.


The facade (with business delegate pattern) provides/establishes a good separation of tiers because the clients only use the facade and never, never, never the business objects directly behind the facade, regardless of you use EBs or plain java objects. So the facade contains only remote session beans (SFSB/SLSB) which insantiates the plain java objects or find/create the entity beans respectively. Because of the remoteable session facade you can build reusable modules (jar files) which can also be used in cluster environments. But I say it again: It doesn't matter if you use plain java objects or entity beans for business objects.


About Entity Beans, I heard many people suggest avoiding that since some application servers really have poor performance to handle it, and it is right as in the reply that it causes nightmare for performance due to activation/passivation/load/store of the bean. You are right; maybe JDO is better than Entity Beans.


Activation/Passivation can cause performance problems due to high disk I/O. Otherwise if you use plain java objects there is no pooling of objects (since you code one). In this case for each client a new object has to be instantiated. This can also influence the performance (bring object in memory, load data from DB, GC !!). If performance plays a crucial role for your application you have to check (prototype) if entity beans are good enough. But as I told you in my first reply, I recommend to use a OR-mapping tool (not for TX, only for db access stuff like mapping, caching, dirty reads, bulk updates, and , and , and).
I dont know JDO in practice. I only know that TopLink and some other OR-Mapping tools implement the JDO spec, also some CMP containers.
 
Thomas Hofmann
Ranch Hand
Posts: 72
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


the answer about keeping the complexity down then using one big / fat session facade can keep the complexity down since clients only know one facade rather than many beans.
That is the reason why you should use a facade, but also in the case of (local) entity beans as business objects.


Sorry, I was a little bit unclear here. A facade can exist of several session beans, each session bean is a facade to it's business objects. So there is no big/fat facade.
 
Alex John
Greenhorn
Posts: 21
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thank you for the clear and good description reply.
We are getting closer to the real problem that I addressed.
As you said :


facade can exist of several session beans, each session bean is a facade to it's business objects. So there is no big/fat facade.


This can be right, but I see in my experience that there is a trend to avoid using so many EJB / session beans or I would like to say a trend to avoid using so many (expensive) components.
This approach then put all business objects together under one big facade. Big here means these facades handles many business objects as possible, and simply delegates the request, and these business object should not be Session beans and should be just simply Java class... The reason is because the big facade handles all your need includes transaction, pooling, security and etc.
It seems to be right approach but addressed some problems, and I like your reply about to build a prototype to evaluate the performance/scalability requirements. But sometimes we cannot perform this prototype due for some reasons (like doing SCEA exam part II).
[ February 23, 2003: Message edited by: Alex John ]
 
Thomas Hofmann
Ranch Hand
Posts: 72
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Alex,
I'm astonished that you follow some trends to create an architecture.


This can be right, but I see in my experience that there is a trend to avoid using so many EJB / session beans or I would like to say a trend to avoid using so many (expensive) components.


Your architecture has to address both functional and service level requirements. So you as the architect has to find a proper solution regardless of a trend.
What is the alternative of a remote session facade using SLSB/SFSB, especially if you have to use J2EE (FBN!!) ? How can you avoid using such components (BTW: SLSB are quite lightweight components)? If you build an n-tier architecture you has to provide distributable components. So do you prefer CORBA, pure RMI, TCP Sockets instead ? So what is the current trend .
Thomas
 
Alex John
Greenhorn
Posts: 21
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In my opinion following trend in Architecture sometimes not really bad as long as they are
good and positive to deliver better functional
and service level requirements.
Maybe I am wrong to use "trend" as a word to describe here, but I see some positive points, even I don't really agree .. that's way I bring to this forum to see others opinion
In this approach, it doesn't tell you not to use EJB, but to minimize it. For example it doesn't recommend you to use one facade which consist of many EJBs. Even Stateless EJB is the lightest, but there are still extra cost. But also this approach is not so modular which may give some problems.
[ February 24, 2003: Message edited by: Alex John ]
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic