Aaron Mulder wrote:
>
> (Sorry, I stole this message from the other list)
>
> On Thu, 20 Jul 2000, Rickard [iso-8859-1] �berg wrote:
> > I think you need to move your understanding of a jar from the practical
> > towards the intention of a jar.
> >
> > What is an EJB jar?
> >
> > It is the smallest possible assembly of components. If you have two
> > components that are directly dependent on each other in order to
> > implement a specific application then they should be in the same jar.
> >
> > So, the first question is: why have you put two interrelated components
> > in two jars instead of one?
> >
> > The second is: if there are indeed good reasons for having two jars, you
> > must make it possible for them to "know the face" of each other.
> > Inter-faces. So, by placing the interfaces of one bean in anothers jar,
> > that another bean will be able to inter-face with the first one. Do you
> > see?
>
> So from the technical perspective, I guess the problem is that
> each JAR has its own classloader? If you don't put the interfaces for all
> the beans in all the JARs, they can't access each others' classes since
> they're in the wrong classloader? I guess I hadn't really thought this
> through. I have always thought more of a big app with lots of
> interrelated beans, but all in separate JARs so they could be managed and
> updated independently. But it sounds like there's a serious disadvantage
> to this approach.
Actually, if all of those beans comprise one app, you probably don't
want to update them independently. They (and the application client
layer) will probably be managed as a unit. This makes peoples lives
simpler by giving them less to manage.
The interface that an application exposes to the outside world is liable
to be _very_ tightly controlled and loosely coupled - otherwise the
managing change in an enterprise with many integrated applications is
extremely problematic - the entire infrasctructure of the company
becomes brittle, causing the company to become unable to respond to
competetive situations, causing the company to die. A lot of
organizations are going toward messaging for application integration
(XML and EAI being the TLA buzzwords of choice in that domain).
All of that is a long way of saying, "If two beans are tightly coupled
to the point that one needs the other's interface, they'd _better_ be in
the same app. and therefore jar."
Of course a lot of people will ignore this advice (some because their
situation is different).
> However, if a client can dynamically download the interface
> definitions it needs to operate (assuming you enable a security maanger
> and so on), why can't one EJB dynamically download the interfaces it needs
> for another EJB? Why would it have to ship with them?
>
> Thanks,
> Aaron
>
> > Let me be explicit:
> > Bean A has following classes:
> > ABean - the bean
> > AHome - the home interface
> > ARemote - the remote interface
> > Bean B has following classes:
> > BBean - the bean
> > BHome - the home interface
> > BRemote - the remote interface
> >
> > Bean B wants to access bean B. As always, in order to talk to components
> > through an interface, that interface must be available. So, package
> > ABean,AHome and ARemote in A.jar and deploy, and package BBean, BHome,
> > BRemote, Ahome, and ARemote in B.jar and deploy. Any B instances can now
> > access the A component.
> >
> > Makes sense?
> >
> > regards,
> > Rickard
