This idea of publishing the beans held by an EJB server on another service
sounds a lot like the CORBA Trader service.
The problem I've always seen with this solution, is that it is simply a
mechanism of indirection. You still need to know were the service is and
find it directly. It may limit the number of Internet addresses and/or
naming bindings you need to deal with but it is not location transparent.
A JNDI driver may provide this type of global service. LDAP implementations
come to mind. In addition to providing a naming service LDAP is also a
directory service. This means you can do searching on the a entries by
properties. List all the color printers in building A or list all the beans
that provide access to employee data.
Richard
-----Original Message-----
From: Bob Pecor
To: [EMAIL PROTECTED]
Sent: 3/16/99 10:42 AM
Subject: Re: Bean access to server info
Still, these are all work-arounds for the fundamental problem:
EJB provides no way to get info about the container or server
at bean class initialization time. There is some context info
available to a bean instance, but this doesn't help.
Richard, I had in fact already implement just what you
suggested but as you say, "ugly, ugly, ugly."
This is actually part of a larger problem concerning object
location transparency. How does a client use the object if
neither the server nor object class publicizes its location.
I realize that the location is published via to a local
service but the problem of finding hosts on the network that
may serve up the required object is problematic: either you
know a priori where an object is or you are out of luck.
If, however, the Bean class (or better yet the EJB server)
were able to publish the location of the bean to a well-known
service (that by convention all clients would query) we might
get a step closer to "object location transparency" since the
object lookup code could be written once (robustly) and used
by clients.
Just an idea:-)
Bob
Bob Pecor
Vanguard Cellular Systems, Inc.
336.286.1742 (Voice) 336.286.1881 (Fax)
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
-----Original Message-----
From: Constantine Plotnikov [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 16, 1999 10:53 AM
To: [EMAIL PROTECTED]
Subject: Re: Bean access to server info
Hi!
Another variant is to have an object on JNDI or RMINaming which
contains
properties needed for you object and just lookup it and use. The
only
property you will need is where to get the object.
You can also initialize settengs from plain text read from some
URL.
The problem is that it is unspecified if how you can add object
to
JNDI
namespace before use of any related object. I think that we
maybe
need
something like "EJB Service deployment descriptor" for protable
way
of doing things like this.
Constantine
Rickard ?berg wrote:
>
> Hey
>
> Bob Pecor wrote:
> > I understand that I could manually put the info I want in a
number
> > of places but that is not an implementation-independent
> > approach: if I change vendors I must change the hard-coded
> > info. I would rather "discover" the info dynamically at
class
> > initialization time.
>
> I understand, and agree. A workaround would be to create a
number
of
> properties-files which contains the various info for the
servers
that
> the EJB:s could be deployed with. Upon runtime you could try
them
out in
> sequence to determine which is the right one. (ugly ugly ugly,
but
might
> actually work and requires less work than manual hardcoding).
>
> /Rickard
>
> --
> Rickard ?berg
>
> Computer Science student@LiTH
> @home: +46 13 177937
> Email: [EMAIL PROTECTED]
> Homepage: http://www-und.ida.liu.se/~ricob684
>
>
========================================================================
===
> 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".
========================================================================
===
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".
========================================================================
===
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".
===========================================================================
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".
