Re: [orbitcpp-list] General information

[Phil D. <ph...@us...>]

Paz Offer writes:
 > Thanks Phil,
 > Very helpfull information indeed!
 > Please bare with a couple of more questions (if I may) it would realy help 
 > me (please,please):
 > 
 > Regarding the Activation issue:
 > 	Is the OAF is a fully CORBA compliant feature?
 > 

No, activation is unspecified in corba. The OAF apis are proprietary.

What is 'sort-of' specified is how an implementation repository should
work.

Basically

1) The Object IOR of a 'persistent' (i.e. long-lived) object contains
the destination of the 'implementation repository' (IMR) service in it

2) The client makes a call on a method of the object pointed to by the
IOR

3) The IMR gets the call, creates the object (and could conceiveably
negotiate with the orb behind the scenes to load a dll if required),
and then forwards the request.

 > I done some reading about CORBA, and nowhere did I find (yet) any mention 
 > regarding activation - in the sence that (MS) COM does it:
 > a.	COM server is registered with the system registry..
 > b. COM runtime will - find the dll, activate the object and
 > download the dll when all is done..

Yep - COM specifies activation (albeit a bit crappily - requiring a
'registry'). CORBA doesn't. Clients assume that objects are long
lived. For similar functionality, people tend to do the following:

1) write a long-lived 'factory' object, who creates the objects. (like
com factories or EJB Homes)

2) register the factory with a corba naming service

3) use some 'magic' to load the factory when people attempt to use
it. (either by the implementation repository scheme described above,
or by a naming service which automatically instanciates factory
objects on demand - this is what gnome does)

I intend on writing an IMR based on OAF (if it's a good fit) in the
medium term. Don't rely on this though (unless you want to help ;-)

It might be worth looking at the gnome nameserver stuff to see if this
fits your needs.

Cheers,

Phil