I've seen very little discussion of the packaging of EJBs. There are two
facets, as I see it, of packaging. One is the logical packaging - which
Java packages are used for which classes. Then there's physical packaging -
how many and what JAR files, and where are they deployed.
First the logical packaging scheme. Often each bean is in its own
subpackage. Under that, there are other subpackages.
The PetStore app does something like (eliminating all the com.sun.j2ee etc
etc)
customer.ejb - contains the bean classes themselves
customer.model - contains the serializable objects that the bean returns
I've also seen
customer.server - the bean impl class, other server-side helpers
customer.shared - classes needed by both the client and server
(serializables, exceptions)
customer.client - classes only needed by the client (rebinding proxies etc)
What other logical packaging schemes are out there?
Now the physical packaging aspect. There's always at least one JAR, the one
with the deployment descriptor that gets deployed into the server. It must
have the EJB interfaces, implementation classes, and other server-side
helpers.
However, there are also shared classes, like the serializable Model or
Detail objects that are exchanged between the client and server, any
application exceptions, etc. Since these are needed on the server, as well
as any client that uses the bean, I'd say it makes sense to have a second
JAR for each bean, called perhaps BeanShared.jar, that must go into the
server's and the client's classpath.
I can see the case for yet another JAR! Let's say you are building a bean
for resale to many third parties. There may be some client-side proxies
that you build to encapsulate JNDI lookup, maybe some initialization logic,
smart failover or retry, etc. These classes are only needed on the client,
so would you package them in a third JAR, say, BeanClient.jar?
With the second logical packaging scheme above, we now have congruent
logical and physical packaging. That is, each of the three Java packages
are packaged into separate phyical deployment units (JARS). In pre-EJB
architectures, I've found that it's usually hard to get the physical and
logical packaging to overlap. It seems like a good idea if it really works.
Any comments?
----------------------
Kenneth DeLong
Senior Consultant
Valtech, Inc.
Cell phone: 510-517-5839
Every complex problem has a simple answer - and it's always wrong.
===========================================================================
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".
