----- Original Message -----
From: Jorgen Thelin <[EMAIL PROTECTED]>
> Isn't this a feature your chosen EJB server should be providing?
Our EJB Server (IAS, which stands for Inprise Application Server, not
iPlanet App Server! Time to give your product a *real* name Inprise.) does
an excellent job of failover through the use of its SmartAgent technology.
But even so, there are some failures that require the method to be invoked a
second time to recover. Also, I think you saw my point about other processes
that can be invoked upon non-recoverable failures.
> Can you not simplify the situation you have to deal with by adopting
> some sort of "coding convention"
> - e.g. have every business method declared as throwing a RemoteException
> and a company/application specific exception, say InameAppException in
> your case, with suitable sub-types for more fine-grained error reporting
> - like "SalaryException extends InameAppException".
Probably a base exception class for all application exceptions is
reasonable.
Best Solution
===============
After reading more about the JDK 1.3 Dynamic Proxy capability, I'm much
excited about the possibilities this opens. Also, Rickard �berg
(http://www-und.ida.liu.se/~ricob684/java/smartproxy/docs/) had posted a
(conspiculously similar approach) way back in 1998 to solve the same
problem. His approach generates a source file, compiles it, and returns the
proxy class on the fly using JDK 1.2.
Other Solutions
===============
1. Reflection
I think the reflection approach to solving this problem destroys the whole
OO-interface cleanliness, and forces the developer to invoke methods using
Strings and sometimes complex object arrays. Exception handling then has to
resort to some kind of a convention. Pretty low marks from a design
standpoint, although it accomplishes the task.
2. Encapsulation
Without resorting to dynamic proxies, the next cleanest design involves the
encapsulation of the remote reference with a class specifically designed to
implement the same interfaces as the remote reference. Without a code
generation tool, this approach is downright painful, and difficult to
maintain.
jim
===========================================================================
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".
