As with any program, there is always a wishlist of things to do.

Use ORT so that the ImR-ified IORs doesnt have any information about the ImR_Activators. Right now, even though, the ImplRepo_Service is the one that is exposed to the client, the IOR will have a reference to the ImR_Activator. By using ORT features, we want the IOR to refer to the ImplRepo_Service rather than the underlying ImR_Activator. That way the ImR_Activator is totally blocked from the client using the ImR service.

For the above mentioned purposes, we can say that the ImplRepo_Service acts as the gateway which receives requests on behalf of the actual ImR_Activator.

The ImplRepo_Service will now need a new IDL method 'create_object'. The create_object method will take the interface_repository_id of the object that has to be gatewayed (ImR_Activator's) and the CORBA::Object_ptr of the gatewayed object. And, using these two will create an object which will point to the ImplRepo_Service and will also know that the ultimate receiver is the ImR_Activator.

So, this is how it works.

As before, we will first run the ImplRepo_Service. And, then run an ImR_Activator. We will use interceptors and in the post_init method, we will add an ior interceptor which will have the ImplRepo_Service object. By this, the IOR that is generated will actually point to the ImplRepo_Service rather than ImR_Activator. So, the IOR which is visible to the client will show that the IOR actually points to the ImplRepo_Service.

When a client sends a request to the ImplRepo_Service, the request will come to ImplRepo_Service which will send the request to the actual ImR_Activator.

Use the AMH features to improve the TAO IMR performance.

In the IDL interface, but not used on the server side or fully implemented in tao_ImR.

Only cooperative shutdown implemented right now. Since we keep track of the Process ID, then we could kill the server if it doesn't cooperate.

Nothing yet.

Nothing really here. There is two main things I have in mind.

First, the security service would be useful to restrict access to some of the Administration methods

Second, without a security service we should provide some sort of flag to the ImR that disables the Administration methods. That way, the database can be set up with the servers in a controlled run of the ImR. Then the ImR could be run again reading in the database without Admin access.

Nothing yet.

Nothing yet.

As of now, the support is only to be able to have the information about a registered server written to an XML file. Have to support retrieving information from the XML file to be able to do any actions on the registered servers.

We can now successfully register an ImR_Activator. But, we have to yet provide support to gracefully unregister the ImR_Activator from the ImplRepo_Service. The ImplRepo_Service then has to try to transfer the servers that were registered with this instance to other activators.