> Are we advocating that the business interface, that is used for local
> objects, have RemoteExceptions listed for all methods. It will have to if it
> is also to be used for the RemoteInterface. This seems strange considering
> that we are now dealing with local state/details objects are implying that
> they are remote. This really is going to cause confusion for the client side
> developer. Maybe I am reading this wrong. Maybe what people are really
> saying is that the bean and state objects are implementing the common
> business interface.
I believe you hear people saying different things. Toms solution is
having bean and state objects implementing the same interface. I think
it is probably a very good solution when you are looking at the need for
rapid change from EJB to non-EJB that they obviously are facing. (Did I
get you right Tom?)
However, the discussion started out when Laird came up with his
proposition of how to work more abstractly with the EJB implementation.
To me the most interesting use for that is to wrap entity beans, as I
for one am not too sure they suit my needs in every situation. The good
part for me would be to have a clean interface with an implementation
layer that either redirects calls to entity beans or works with an
object database. In the end it will help me to keep my design between
different system versions.
Whichever way you wrap things you will end up with an interface that
either throws RemoteException or catches it and throws a local
exception, which could be a better thing to do. Some people would catch
it and not do anything, but I normally try to be a nice guy. :-)
> One thing to consider before moving totally away from entity beans and to
> session beans with OO databases. Entity beans should not be just data
> holders they should do some useful work on their internal state and help
> reduce the amount of the data sent across the network.
No doubt about it, I agree totally with your argument in the case where
modification can be kept centrally. I'm just concerned about situations
where you need different levels of state. The travel industry is a good
example where the standardized EJB solution probably will falter.
Regards
/Marcus
Marcus Ahnve
Sun Java Center
Sweden
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
