I am currently working a migration of our system to EJB for several reasons, 
mainly to be able to use clustering to achieve higher performance and 
availability.

Now, our current system is very service oriented (through CORBA) but under this 
the data model actually seems to be fairly well suited to port over to Entity 
beans in a nice way.
So the obvious first choice would be to clasically migrate our existing data 
objects as entity beans and then design a session bean facade for every service 
interface.

However, the system is very complex and for instance the administration 
interface must administrate almost all types of entity objects which makes the 
session facades very big! (up to almost 100 methods for some) 
Now, I am not happy with this interface size (who would?) and was hoping that 
EJB would give us a way to move away from this...

So my first though (even before I knew about the details of EJB) was to 
actually distribute parts of the business logic IN the entity beans.
Now, it seems this is somewhat unorthodox (blasphemy? ;-) ) to do this in EJB, 
or? 

At least from my pow, this could actually make the business logic simpler 
despite many people claiming the opposite? 
Naturally, this means that the business logic is spread in many places, but is 
it better to have a HUGE service interface? 
Also, each objects business logic could then potentially become much simpler...

Anyone have any feedback on this? 
Anyone did this with a big object model (100+ classes)?
And how could all this impact on clustering? (which is very important for us)

Or, does anyone have an alternative to make the session interfaces more 
manageable? 



View the original post : 
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4041696#4041696

Reply to the post : 
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4041696
_______________________________________________
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user

Reply via email to