RMI Boundary, Package Visibility, and Exception Propagation

R

robertbrown1971

When trying to properly stucture package visibility in a client/server
application the question of exception propagation comes up again and
again. I was wondering if people could point me to any best practices
for this problem.

One widespread practice is to make sure that all the exceptions in the
server derive from one DomainException, that way you can define all
your RMI signatures to throw DomainException and RemoteException so
that, as your application evolves, you can introduce new exceptions
without breaking client signatures - they can always catch
DomainException and rest assured that they caught every exception you
going to throw including future ones. The problem is that the client
will sometimes want to disambiguate between various subtypes of your
DomainException such as in the case when the database is down. That
brings us to the question: should all the server side exception be
contained in a client accessible package?

Thanks,

Robert
 
E

E.J. Pitt

One widespread practice is to make sure that all the exceptions in the
server derive from one DomainException, that way you can define all
your RMI signatures to throw DomainException and RemoteException so
that, as your application evolves, you can introduce new exceptions
without breaking client signatures - they can always catch
DomainException and rest assured that they caught every exception you
going to throw including future ones. The problem is that the client
will sometimes want to disambiguate between various subtypes of your
DomainException such as in the case when the database is down.

I think there is almost always a need to distinguish between exceptions
which indicate that the call can't even start (e.g. bad config, database
is down, ...), exceptions which indicate that the call failed but could
be retried (temporary resource shortage or overload), and exceptions
which indicate that the call failed due to a semantic (business rule)
error at the server, as well as RemoteExceptions which should be
entirely separate again (and it is a pity that they weren't better
structured along these same lines).
That
brings us to the question: should all the server side exception be
contained in a client accessible package?

If you mean putting them all into a single Java package, I don't see the
connection, and I don't see any reason to do it. General Java practice
is to put exceptions into the packages that throw them, and this works
well enough for most people.
 
R

robertbrown1971

EJ

What I mean is that the RMI client (say a struts based app) is going to
need a jar in its path from which to import the exceptions. Now say
some DeepInternalServerException is thrown and the client needs to
differentiate it from some other exception, would the client have to
install a jar in its path that contains the whole deepinternalserver
package? I know space is not a limitation these days but for aesthetic
reasons I think it would be nice to have the jar that the client needs
only include the serializable classes and remote stubs not the whole
server app. This separation works well until you hit exceptions and
then you need to install your whole server jar in your struts path.

Thanks for the first answer by the way. It's a very useful distinction.

- Robert
 
E

E.J. Pitt

Well all the client needs are the exception classes, not the whole
megillah, and you should certainly never deploy server code to the
client. RMI systems generally need a JAR that are common to the server
and the client, certainly including all remote interfaces and exception
classes. There is no need for this JAR to be restricted to a single
package, it's only a mechanical question of how you build the JAR.
 
R

robertbrown1971

E.J.

Thank you so much. Last very short question. Could you confirm that you
would see it roughly as follows:

Say you have the classes for your server app in two packages:

"com.mycompany.internalserver" and "com.mycompany.deepinternalserver"

There is a third package of RMI api facades "com.mycompany.api" which
includes all the remote interfaces, serializable value objects, etc -
basically, stuff that client needs to talk to the server.

So then the server.jar will include all three packages whereas the
client.jar will only include "com.mycompany.api" and then just the
exceptions (not whole packages) from "com.mycompany.internalserver" and
"com.mycompany.deepinternalserver". So the client will still import
classes from packages with internalnames but they will only include
exception classes not all classes from the internal server packages.

I guess I would rephrase as follows: is it a good idea from the "best
practices" perspective to put all the exceptions that are shared into
some "com.mycompany.sharedexceptions" package or is it ok for the
client to reference then from the internal packages.

Thank you again!

- Robert
 
E

E.J. Pitt

E.J.

Thank you so much. Last very short question. Could you confirm that you
would see it roughly as follows:

Say you have the classes for your server app in two packages:

"com.mycompany.internalserver" and "com.mycompany.deepinternalserver"

There is a third package of RMI api facades "com.mycompany.api" which
includes all the remote interfaces, serializable value objects, etc -
basically, stuff that client needs to talk to the server.

So then the server.jar will include all three packages whereas the
client.jar will only include "com.mycompany.api" and then just the
exceptions (not whole packages) from "com.mycompany.internalserver" and
"com.mycompany.deepinternalserver". So the client will still import
classes from packages with internalnames but they will only include
exception classes not all classes from the internal server packages.

I guess I would rephrase as follows: is it a good idea from the "best
practices" perspective to put all the exceptions that are shared into
some "com.mycompany.sharedexceptions" package or is it ok for the
client to reference then from the internal packages.

I've already answerered that, haven't I? (a) I would have three JAR
files: server, client, and common. (b) I wouldn't have a strong
association between JAR files and packages, I'd tell my build.xml or IDE
what classes go into which JARs (i.e. not just by package). (c) I
wouldn't normally put exceptions anywhere except in the packages that
throw them. It's up to you though, there are arguments both ways.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads


Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top