[omniORB] Implementation repository ?
Gary D. Duzan
gdd0@gte.com
Wed, 02 May 2001 15:34:18 -0400
In Message <3AF05CDF.1000206@sympatico.ca> ,
Stefan Seefeld <seefeld@sympatico.ca> wrote:
=>Gary D. Duzan wrote:
=>
=>> Implementation Repositories are non-standard things, and the
=>> OMG is unlikely to specify them any time soon. (There may be
=>> something in the new CORBA Component Model that addresses this,
=>> but I haven't gotten into that much detail yet.) The CORBA LifeCycle
=>> Service could potentially be used for implementing one, but the
=>> one I know a bit about (Orbacus', via Michi Henning) works by
=>> launching processes that implement objects and issuing LOCATION_FORWARDs
=>> to them once they are started.
=>
=>
=>I thought that's the bit about IMRs that *is* standard, i.e. spawning
=>new processes and
=>using LOCATION_FORWARD to redirect the client. How else can you do that
=>if you
=>want it to be scalable (i.e. the core process to be free of any
=>knowledge concerning the
=>types that are being served) ?.
The LOCATION_FORWARD itself is standard, but the actual service
which listens on one IOR, launches something if necessary, and
sends the LOCATION_FORWARD response to point the caller to the real
object is not. In particular, there is no standard way to register
the startup command with a real IOR and get back a proxy IOR, and
this is just the simplest case. A fancier Implementation Repository
might want to pick apart the IOR it receives from a client and use
part of the object key as a parameter to the startup command. Or
perhaps something simpler like having a number of real IORs and
returning them to clients in a round-robin fashion for load balancing.
Orbacus' IMR allows particular hosts to be specified with the
command and includes its own remote execution mechanism to implement
it. The different possibilities make it difficult to standardize,
and it leaves vendors some room to differentiate their products.
Gary Duzan
Verizon IT