marc fleury wrote:
> |Now, couple that with a Jini-based deploy interface and you have
> |something really interesting.
>
> what do you mean, expand
Well, it's how the actual deployment step is done, i.e. getting the JAR
to the server. With Jini there are two ways:
1. Use pull: each server has a Jini service that "listens" for available
JAR's from a central repository, which is found form the LUS (Jini
LookUpService, similar to JNDI but more dynamic). When a JAR is added,
it is downloaded and deployed.
2. Use push: each server has a Jini service that one can call
deploy(URL) on. The deployer tool can find the servers by looking them
up in the LUS.
1. is good because you just say "here are the JAR's to be used for this
cluster", i.e. put them in the central repository and let the servers
find them by looking them up. Whenever you start a new server it will
load them automatically, i.e. you don't have to deploy them manually.
2. is good because you get immediate response whether the deployment
succeeded or failed, and you have more control over when the actual
deployment is done.
Both are useful, and they're not exclusive, i.e. both can be used at the
same time.
More clear?
/Rickard
--
Rickard Öberg
Software Development Specialist
xlurc - Xpedio Linköping Ubiquitous Research Center
Author of "Mastering RMI"
Email: [EMAIL PROTECTED]
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development