Next Previous Table of Contents
One often mentioned problem, when talking about applications which provide their services via CORBA, is how to start and access these services. Solutions like making apps write the IOR of an object somewhere into a file in the filesystem or similar approaches are just hacks ;-) . Better use KActivator, since it can automatically, on demand, start servers for you or use already running ones. This is accomplished with the help of the mediators for BOA/POA and the IMR (Implementation Repository), both provided by MICO. Fortunately you don't have to deal with IMR entries and the mediators.
Before you can use KActivator to start a server for you, you have to register the server's service. There are two possible ways, the last one is highly recommended though:
For the second point it's important that the .desktop file is available for KRegistry, by placing it in a directory which gets scanned by the registry. If your application has already a .desktop file in the applnk tree for example, then you're fine with adding the necessary fields in there. Otherwise the directory named "services" (either system-wide or user-local) is the best place for it. If you provide the CORBA service information this way, then KActivator will automatically detect it and register it automatically at the IMR. This means that it is immediately available for KActivator and thus to your client app. And since KRegistry is such a cool thing :-) , you can do all this even at run-time, when kded is running. Just place the .desktop file in one of the right directories for it and KActivator will update the IMR on-the-fly. The same applies obviously for just deleted or modified .desktop files, which will make KActivator adjust the IMR. Now you might get the idea why this is the preferred way :-)) .
Now that you know how to register CORBA services you will want to know how
to "access" it. activateService()
is your friend here. Simply pass
it the name of the service, the repository id of the server object and the
object's tag and it will return you a functional object reference. That's all :-)
Depending on the service's activation mode, KActivator will either return a reference to an already running server or it will start a new instance.
One note about the returned object reference: This is a virtual reference, which means that that server object is started when the first call is invoked on this reference, thus making your server get started "lazy", only on-demand. But that's just additional information, you don't have to deal and know about it at all. Just be happy with your functional object reference :-) .
Want some examples? Here we go:
This is how a .desktop file could look like, assuming that the commandline "--server" starts the app in CORBA server mode:
Name=MyApp Exec=fooblah CORBAExec=fooblah --server X-KDE-RepoIds=IDL:Foo/Blah:1.0#MyFoo X-KDE-ActivationMode=shared
If KActivator "gets" this file, it will register the service and then you're able to do something like this:
... KActivator *activator = KdedInstance::self()->kactivator(); ... CORBA::Object_var obj = activator->activateServer( "MyApp", "IDL:Foo/Blah:1.0", "MyFoo ); ...
The above example will either start a new fooblah instance or connect to a running one.
For further information please have a look at the examples in kdelibs/corba/tutorials/kded .
The example application there registers the server manually via registerService
.
Please note: The server has to be started by kded in order to make KActivator return a reference to a running one. Executing "fooblah" from somewhere else will not make KActivator use it. This is a problem for persistent servers like KDesktop for example. But there's a solution available, just read the next chapter about the KDE Naming Service :-) .
Next Previous Table of Contents