----- Original Message -----
From: "Guy Rouillier" <[EMAIL PROTECTED]>
> Please realize that I am still climbing the EJB and JBoss learning curve
> myself. As long as the clients (which would include some EJBs in this
> discussion) are using a specific nameserver, what difference does it make
> what JBoss does with its own? In other words, if all clients are looking at
> (e.g.) 192.168.1.100, then the fact that JBoss is running one at
> localhost:1099 is immaterial. Right?
Well, the goal is to support beans running on multiple containers without
hardcoding lookup hosts. On the server side, your beans will need to talk to
other beans. In some deployment situations, these beans will live in containers
located on other machines. Your EJBs should never pass a host location to
InitialContext(), the server should configure this for you.
In the case of jBoss, your EJBs will automatically look up bean references in
the server's name service (localhost:1099). The docs refer to a situation where
you can look up a bean on another machine but the lookup is hardcoded into the
jboss.xml deployment descriptor for the bean. This is OK in some very limited
cases, but would never be taken seriously in a *real* deployment situation.
As I said before, server architectures get around multi-vm bean lookup using
various mechanisms. Borland uses a "smart-broadcast" technology called OSAgent.
Other servers use a federated namespace, or a single name service. I was trying
to setup the single namespace approach with jBoss, but it looks like it can't be
run that way. At least, it appears that the container will not deploy beans
unless it has its own (local) name service running.
jim
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user
