Rickard �berg wrote:
>
> Hi!
>
> Toby Allsopp wrote:
> > I agree with Christoph. If there's a global description of the entire
> > system, why not just package the whole thing as one EAR?
>
> For maintenance. It is impractical to package and update a large system
> as one single EAR.
Ok, so it's the packaging that's impractical, not the description of the
system? I guess I was envisaging a system so vast and complex that a
single description of its structure would overwhelm any mere mortal.
Although I suppose this description could be generated.
> > Although I'm
> > always a little nervous about relying on emergent behaviour - it's like
> > simulating a flock of birds or something: each bird knows how it should
> > react to the birds around it and knows how to avoid obstacles and there
> > is no one bird that has the whole formation mapped out - it just
> > emerges. Maybe this is cool and maybe it's asking for problems.
>
> I'm not sure what you're referring to here.
I am not surprised. Something about birds, by the sound of it.
> What would be the potential
> problems? (Other than namespace problems)
Well, birds crap everywhere, and then there's the pecking and where to
find all the mice or worms whatever birds eat. Seeds, maybe. I guess the
namespace could get cluttered, what with them all being called Polly or
Tweety.
I think I was trying to make a point about how the behaviour of the
system (in this case the dependencies between applications) can emerge
from the behaviour of each component (in this case each application's
own dependencies). The problem with this in this specific case (the J2EE
one, not the flocking birds) is a bootstrap one - each application can
describe its dependencies but, unless you include the URL of the EARs
that fulfil those dependencies, there isn't any way to find what needs
to be deployed to fulfil them.
Toby.
--
Toby Allsopp
Energy Research Lab
Peace Software International Ltd
Ph +64-9-3730400
