[omniORB] Interface Repository objects

[Duncan Grisby]

On Wednesday 27 February, "Warren Brown" wrote:

> If I use a nameservice for instance, I resolve the initial reference to
> the nameservice, narrow it, then use the object bind, rebind resolve
> etc.
> Do I do the same sort of sequence with the interface repository. ie
> resolve, narrow then use the object.
> Will that give me an object that I can use dynamic invocation or will it
> give me an object to write idl's on the fly?

If you're using DII, you don't need to narrow. Narrowing gives you a
type-specific proxy object that allows you to use the static
invocation interface. If you're not using that, you can use a generic
CORBA::Object proxy. Just call _request() on the CORBA::Object,
without narrowing.

The interface repository just allows you to find out the operations
(and types) you could use with DII. It doesn't have anything to do
with actually invoking those operations.

Of course, if you don't have a human interpreting the meaning of the
data in the IfR, there's not a whole lot a program can do with the
information.

> Where, when and why would I use a trading service? I don't really
> understand the similarity it's supposed to have with yellow pages.

Imagine you have a big office building with lots of printers in it.
Different printers have different capabilities -- colour, duplex
printing, speed, location, etc. You model each printer as a CORBA
object, and store the object reference and the printer's properties in
the trading service. A client program wants to print something, so it
queries the trader service to find an object that matches the
requirements for its print job. It may have to weigh up several
sub-optimal possibilities.

That sort of thing can only possibly work in very constrained
application domains. If the client has no knowledge of the printer
CORBA interface, it doesn't do it any good at all to be able to find
an object reference based on some properties. It can look the
interface up in the IfR, but then what can it do?  Without strong AI
capabilities, it isn't going to be able to understand the steps needed
to actually cause something to be printed.

HTH,

Duncan.

-- 
 -- Duncan Grisby  \  Research Engineer  --
  -- AT&T Laboratories Cambridge          --
   -- http://www.uk.research.att.com/~dpg1 --