[omniORB] Finding methods / part 3

[Stefan Seefeld]

Casillas_Juan_M/madrid_tecnologia@sinvest.es wrote:

>    to do that in a distributed way ... Imagine the following scenario:
> 
>    Program A wants to know what Laser Printers are out of paper;
>    There are programs monitoring the printers say, these monitors
>    check periodically the printer to see its status and send events
>    about it; and in the other side, these monitor have a CORBA interface
>    so you can manage the printer from another program:
> 
>    A program monitor has:
>          1) code to check the printer periodically
>          2) code to send events to the Eventchannel or something like
>             this (the Communication Adapter) so we can notify the
>             status to other programs
>          3) code to receive events that contain commands
>          4) a corba interface to allow another program manage the
>             printer, just like this program was the monitor
> 
>    so Program A don't
>    manage the printers directly and A don't know nothing about the
>    monitoring programs; Program A and the monitors talks using a
>    event channel or something like this. So to do something useful,
>    A must check:
> 
>       1) first all the printers
>       2) then for the printers available, all the laser printers
>       3) from this, printers that are out of paper.
> 
>    There are 2 ways to do this
> 
>       1) Use the Naming service, register all the monitors on it,
>          and then use object references for all of them from the
>          program A, and use their interfaces to check the conditions
>          but this has two problems: 1) It requires lots of connections
>          to do this and 2) is very centralized, so if A crash, I have
>          problems.
> 
>       2) The other way is to use a comunication media says an Event
>          channel, or something like this, so A can query to the rest
>          of programs (in this scenario, the monitors) for those that
>          are monitoring laser printers, that are out of paper. The
>          monitors that check the conditions (monitors monitoring
>          laser printers that are out of paper) send the answer to
>          program A; so A can use the Monitor CORBA interface to
>          manage this printers. This is way is distributed (each
>          monitor checks itself the conditions) and requires less
>          connections. I think my steps must follow this path

I think trading service is really what you want. You can export
a service ("monitor a laser printer" together with an attached interface).
Then your program can query for services given a list of attributes. Then
it selects and imports the service it prefers, using the returned interface.

Of course, those interfaces have to be known by both, the provider (exporter)
and the user (importer). But that's ok, you have to know *something* anyway
in your client to be able to invoke a service's interface...

Stefan

PS: you need to decide what is an attribute of the interface (for example
laser, ink jet etc.) and what is an attribute of the object (out of paper).
_______________________________________________________              
              
Stefan Seefeld
Departement de Physique
Universite de Montreal
email: seefelds@magellan.umontreal.ca

_______________________________________________________

      ...ich hab' noch einen Koffer in Berlin...