[glue-wg] Problem with LDAP binding inherited foreign-keys

[Paul Millar]

Hi all,

While writing the dCache GLUE2 info-provider, I came across a problem with the 
current GLUE2 LDAP binding.

The problem is that inherited associations are represented twice.

The schema uses three kinds of LDAP class: ABSTRACT, AUXILIARY and STRUCTURAL.  
ABSTRACT is only used for the LDAP class for Entity (GLUE2Entity), all objects 
that are a directly derived from Entity are STRUCTURAL, everything else is 
AUXILIARY.

So:
    LDAP classes for Service and Share (GLUE2Service and GLUE2Share
		respectively) are STRUCTURAL,

    LDAP classes for StorageService and StorageShare
		(GLUE2StorageService and GLUE2StorageShare) are AUXILIARY.

Any published object must have at least one STRUCTURAL class and zero or more 
AUXILIARY classes.

To publish a StorageService, the LDAP object must have GLUE2StorageService and 
GLUE2Service object-classes.  To publish a StorageShare, the LDAP object must 
have GLUE2StorageShare and GLUE2Share object-classes.

In GLUE v2.0, the Share object has a required (i.e., multiplicity of '1') 
association with a Service.  This is represented in the LDAP Schema as a 
required attribute in the GLUE2Share class: the GLUE2ShareServiceForeignKey 
attribute.

The StorageShare object inherits this required association, only it is against 
a StorageService now.  This association is represented as a required attribute 
in the GLUE2StorageShare class: the GLUE2StorageShareStorageServiceForeignKey 
attribute.

Since a StorageShare object must be published as both GLUE2StorageShare and 
GLUE2Share object-classes,  this object must publish the same association 
twice: once once as GLUE2ShareServiceForeignKey and again as 
GLUE2StorageShareStorageServiceForeignKey.

The same problem exists for very many (perhaps all) ForeignKey attributes in 
AUXILIARY classes but is hidden since those foreign-key attributes are 
optional.

I've talked to Laurence about this problem and our preferred solution is to 
delete GLUE2StorageShareStorageServiceForeignKey and have all a StorageShare 
publish their association with StorageService using a 
GLUE2ShareServiceForeignKey.

I believe this approach will work for the other "inherited" foreign-key 
attributes.

This solution has the disadvantage that the association between a 
StorageService cannot be restricted to a StorageService (and not, for example, 
to a ComputingService object).  However, since LDAP doesn't support foreign-
key constraints, such consistency may only be enforced by manual checking 
(gstat2, glue-validation suite, etc).  So, I believe removing 
GLUE2StorageShareStorageServiceForeignKey doesn't loose us anything.

Does this make sense?  Are people in favour of this approach?

Cheers,

Paul.