"Bono, Chris" wrote:
>
> >>>I understand that this behavior is found in some products. But I
> >>>should point out it is not the behavior found in other products.
> >>>For example, in our product you don't need to provide a host/port
> >>>to locate objects, whether those objects run locally or remotely.
>
> When you say remotely, I assume you mean in a clustered environment.
> I was talking two seperate appservers, which are not cluster aware.
> You have to tell jndi where you want it to get its naming context from.
>
> And if you have a stand-alone client app you must tell jndi where to
> establish the naming context (not specific to ejb).
>
> Under the covers I am sure the container has hooked a specific
> naming context in that allows the caller to get at its env. (java:comp/env)
It is not clear to me why clustering (or not) would change the fact that
some products require you to hard code host/port information, and some
do not. Whether our AppServer is deployed in a homogeneous cluster, or
a heterogeneous cluster, or without clustering, it is not necessary to
hard code host/port information in your clients. I understand that
other products behave differently, but this awkwardness is not inherent
in the model.
Our AppServer builds on the design philosophy of VisiBroker, which has
had a long history of minimizing the amount of per-node configuration
that is required. It is the way I prefer to build distributed systems,
and that preference is reflected in the design of our products.
For a couple longer discussions on the ins and outs of clustering, see
our white papers:
http://www.borland.com/appserver/papers/
> >>>IMO, in a well-designed distributed systems you should keep the
> >>>amount of hard-coded information to a minimum. Requiring that
> >>>you provide consistent host/post info to all clients seems like
> >>>a major headache!
>
> I totally agree. However in the cases where you don't have a choice
> what can you do? :-)
Maybe use a different AppServer?
-jkw
===========================================================================
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".
