7. Add Third-Party UIs

To add a third-party UI to an existing service's attribute sets, you must have the service's cooperation. The service can veto your request at any of several points in the process. The steps are:

1. Check to see if the service proxy implements net.jini.admin.Administrable (Administrable).

If the service proxy does not implement Administrable, the service provider has already thwarted your wishes. You won't be able to add a third-party UI directly to the service item's attribute sets.

1. Cast the service proxy to Administrable and invoke getAdmin().
2. Check to see if the admin object returned by getAdmin() implements the net.jini.admin.JoinAdmin (JoinAdmin).

If the admin object does not implement JoinAdmin, the service provider has thwarted your wishes. You won't be able to add a third-party UI directly to the service item's attribute sets.

1. Cast the service proxy to JoinAdmin, and invoke appropriate methods to add or modify one or more UIDescriptors.

You add or modify UIDescriptors in the same manner as you would add or modify any kind of Entry in the service's attribute sets. The JoinAdmin's addLookupAttribute() method lets you add new UIDescriptors. Its modifyLookupAttribute() method lets you modify existing UIDescriptors. Once again, the service provider can veto your request, even at this step, by throwing an exception from these methods.

Once a new UIDescriptor for a third-party UI is successfully added via the process described previously, the third party won't need to add it again. From that point forward, whenever a service registers itself with a lookup service, its service item will include the third-party UIDescriptor. It will also reregister itself with any lookup services with which it is currently registered, so that the new UIDescriptor will appear there as well. Even if the service provider crashes and restarts, it should remember the new UIDescriptor and include it in its registrations after the crash and restart.

On the other hand, the UI, UI factory, and possibly the attributes require class files to be available in some codebase. Although the third party never needs to worry about the UIDescriptor being included in future service registrations, the third party must make sure the class files are forever available at some codebase.

One potential problem with adding a third-party UI is that in a strict client-side security policy, downloaded code will by default only have permission to connect back to the host from which the code was downloaded. In that case, if the third-party UI's codebase is on a different host than the service proxy's codebase, the service proxy won't be allowed to talk back to its host at the behest of the UI. Therefore, for a third-party UI to work in practice, either the third-party UI's codebase must be on the same host that serves the service's codebase, or the client must specifically relax its security policy in order to use the third-party UI.