[omniORB] Object Id and POA reference

Brenneis, Steve steve.brenneis@attws.com
Tue, 17 Oct 2000 11:59:10 -0400


Thanks for the quick response, David.

This leads me to a little more esoteric follow-up. Since the method of
encapsulating these two components is not specified, would it be allowable
for an ORB implementation to accomplish this in another way (e.g. private
tagged profiles)? If so, wouldn't this represent a potential
interoperability issue since GIOP specifies that private profiles, for
instance, are allowed, but clients and servers may not rely on their
presence or absence in any ORB or Request invocation?

There is a concrete reason behind these abstract questions. I am trying to
identify potentials for interoperability failures between ORBs operating at
various levels of CORBA 2.x compliance. I have always been able to trust the
omniORB team to implement in the most standard way, so I am using omniORB as
my baseline for this evaluation.

Thanks again for the help.

Steve Brenneis

> -----Original Message-----
> From: David Riddoch [mailto:djr@uk.research.att.com]
> Sent: Tuesday, October 17, 2000 11:32 AM
> To: Brenneis, Steve
> Cc: 'omniorb-list@uk.research.att.com'
> Subject: Re: [omniORB] Object Id and POA reference
> 
> 
> On Tue, 17 Oct 2000, Brenneis, Steve wrote:
> 
> > I apologize in advance if this is something already 
> addressed in this list,
> > but I searched the archives and couldn't find the specific 
> information.
> > Also, I apologize if this is a RTMS question.
> > 
> > How does omniORB encapsulate the Object Id and POA 
> reference into the object
> > reference as required by chapter 11 of the specification? 
> Is this done by
> > concatenation into the object key of the GIOP IOR?
> 
> Yes.
> 
> 
> > If so, is this standard
> > and where in the specification is this detailed?
> 
> It is ORB specific, and so there is no OMG specification.
> 
> To see how omniORB does it look in src/lib/omniORB2/orbcore/poa.cc.
> 
>      create_key()
> and  create_new_key()
> 
> But please don't rely in this -- it might very well change in 
> the future.
> 
> 
> Cheers,
> David
> 
>