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?