a) If I have naming hierarchy such as
nm="TopLevel" kind="cluster"
|
|
nm="SecondLevel" kind="servers"
|
|
nm="MyObject" kind="servant"
Should the below code correctly get to MyObject
(in other words, is using kind="servant" necesarry).
In my tests it looks necessary -- otherwise I get NotFound.
But wanted to verify.
CORBA::Object_var obj = orb->resolve_initial_references
("NameService");
assert (!CORBA::is_nil(obj.in()));
CosNaming::NamingContext_var namingServer=
CosNaming::NamingContext::_narrow(obj);
assert (!CORBA::is_nil(namingServer));
CosNaming::Name _corbaCosName;
_corbaCosName.length(3);
_corbaCosName[0].id=CORBA::string_dup("TopLevel");
_corbaCosName[0].kind=(const char*) "cluster";
_corbaCosName[1].id=CORBA::string_dup("SecondLevel");
_corbaCosName[1].kind=CORBA::string_dup( "services");
_corbaCosName[2].id=CORBA::string_dup("MyObject");
//IS THIS Necessary?
_corbaCosName[2].kind=CORBA::string_dup("servant");
server = namingServer->resolve(_corbaCosName);
assert(!CORBA::is_nil(server.in()));
b) Second question, if I Have
properly initialized
CORBA::Object_var
can I get from it its naming context?
and with what call (in C++)
thank you in advance,
VSP
VSP
Yes, you need to specify kind="servant".
I recommend you visit my website (www.CiaranMcHale.com) and have a
look at a free book there called "CORBA Explained Simply". Don't
feel compelled to read the whole book. Just read Chapter 4 ("The
Naming Service"). It's a short chapter and I think some of the
information in it will help you better understand the Naming Service.
> b) Second question, if I Have properly initialized
> CORBA::Object_var can I get from it its naming context?
> and with what call (in C++)
The simple answer is: No.
You should think of the Naming Service as a place where server
applications can (optionally) advertise some of their objects.
Just because a client application has a reference to an object
does *not* enable the client application to automatically know
if/how that object was advertised. As an analogy, let's assume
you have a box of cereal in your house. The box of cereal does
not inform you where the cereal was advertised (on a radio station,
on page 42 of a particular magazine, and so on) or from which shop
you bought it. Likewise, an object reference (such as an initialized
CORBA::Object_var) does not tell you if the object reference was
obtained from a Naming Service, a Trading Service, as an "out"
parameter of an operation, via a stringified IOR obtained from a
file/database/web-server, by calling orb->string_to_object() on a
corbaloc string, or some other mechanism.
Regards,
Ciaran.
--
Ciaran McHale ciaran...@yahoo.co.uk www.CiaranMcHale.com
Mobile: +44-(0)7866-416-134 Home office: +44-(0)118-954-6632
In fact based on your
"..
If the server process is later killed then obviously the servant (C++
or Java object) will be destroyed. Then, if the server is restarted, a
new servant
will be created to represent the same CORBA object. What all this
means is
that a future invocation by the client application upon the same CORBA
object
may be handled by a different servant. In turn, this means that a
CORBA object
can be “long lived”, that is, it can survive a stop-and-restart of a
server process
..."
I am reconsidering how I have done something....
I have functionality where I can have more than one 'instance' of the
same object
running on different computers -- a very basic requirement for a
distributed system
that OMG I guess did not consider for the mimimum implementation.
So what I have done was the following:
When my servers come up, they register themselves with naming service
as
ServerName__hostcomputername__processID
-- that's the name that goes into the naming service.
Then the client
traverses the list of the available servers in the naming service
and 'randomly' picks one and contacts it -- that's how I do
'load balancing'.
Right now, for speed of development, I invoke the 'listing' functon on
the NamingService
every time I need to contact a server for a 'series' of synchronious
calls..
Even that is very tedious programming OMG has me doing ... :-)
On top of it, I am now writting a process that 'removes' dead servers
from the naming
service -- so that they do not show up in my listing. Again seems
like a basic
thing for a distributed system (where with distribution I try to
achieve scalability
by distributing work to multiple computers) -- but takes days to
write.
But your paragraph kind of implies that I should not using the
'naming' service
to register the same object with different names....
The other alternative of course, to have some kind of a 'proxy' system
-- I have
read that IONAs corba implementation has done something like that
where
their namign service can act as a 'proxy' to multiple servants (but I
am using
Omni and just thought there is no way I could implement something like
that myself).
So at the moment, I can see that you would not have suggested using my
mechanism
of load balancing -- but I cannot come up with something different
that would be
easy to implement.
thanks again for your answers and the book,
VSP
On Apr 22, 6:02 pm, Ciaran McHale <ciaran_mch...@yahoo.co.uk> wrote:
> VSP <runtime....@gmail.com> wrote in news:81b51f00-d9e0-4277-b960-
> bb2ce2b6b...@q9g2000yqc.googlegroups.com:
> Ciaran McHale ciaran_mch...@yahoo.co.uk www.CiaranMcHale.com