The Artima Developer Community
Sponsored Link

Version 1.1a
The ServiceUI API Specification
by Bill Venners

<<  Page 11 of 12  >>


9. Consistent Serialized Forms

Because the Jini lookup service uses exact matching of the serialized forms of entry fields, it is critical that fields that will be used in template lookups have serialized forms that are consistent across all virtual machines. However, there is no guarantee that implementations of the Set interface, the declared type of the attributes field of UIDescriptor, have consistent serialized forms across all virtual machines. For example, java.util.HashSet, perhaps the most commonly used implementation of Set, does not guarantee a consistent serialized form. As a result, if a UIDescriptor that contains a HashSet in its attributes field is retrieved from a Jini lookup service, the serialized a form of the attributes field could be different if the UIDescriptor is reserialized as part of a template. This means that a UIDescriptor, when retrieved from a Jini lookup service and used immediately in a lookup template, may not match itself.

The Service UI API was defined under the assumption that UIDescriptors in Jini lookup templates might contain non-null role and toolkit fields, but would always contain null in their attributes and factory fields. It was expected that attributes could be inspected on the client side to select between multiple matches of a Jini lookup. Once a UIDescriptor was selected, it was expected that clients would use the factory field to produce the selected UI. Because of these assumptions, the UIDescriptor class was not designed to ensure a template in which all four fields were non-null would work. In other words, the designers were aware that the attributes field could not be used in lookup templates, but did not imagine that anyone would ever need to do that.

When used in templates intended for basic lookup of Jini services, UIDescriptors will likely never have non-null attributes fields. Nevertheless, UIDescriptors used in templates intended to modify the attribute sets of already-registered Jini services could very likely contain non-null attributes fields. For example, to add an object to the attributes set of a UIDescriptor already registered as part particular Jini service item, you must pass a template UIDescriptor that exactly matches the registered UIDescriptor in the attrSetTemplates parameter of either:

Unfortunately, the use case of modifying a UIDescriptor in an already-registered Jini service item was never considered during the initial design discussions leading to 1.0 release of the Service UI API. To address this need, the 1.1 version of this specification narrows slightly the contracts of these methods and constructors:

The 1.1 specification adds to the contracts of each of these constructors a requirement that they copy the contents of the passed Set or Map into a serializable read-only version that has a consistent serialized form across all VMs. This new requirement yields the desired behavior when attempting to modify UIDescriptors already part of service items registered in lookup services.

<<  Page 11 of 12  >>

Sponsored Links

Copyright © 1996-2018 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use