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.
