Finalizing the LDAP implementation of GLUE 2.0
Hello to everyone! I am trying finalizing the initial draft of the LDAP implementation and have a few questions that need to be resolved before I can finish. Question 1: In the Entity class on page 8 of the GLUE Specification, the Association.End has just one field, Extension.Key, but in the Extension class its unique identifier is LocalId. The Extension.Key should probably not be used as its description is "This identifier is not required to be unique; several instances of this class MAY hold the same value of this attribute". So in the Entity class, should Extension.LocalId be specified instead of Extension.Key? Question 2: The relations in the association end list are always specified with the attribute they have to link with. (E.g. Service.ID). There are several reasons why this may not be a good idea. a) In the Entity-Relationship models, relationships between entities/classes/objects are generally specified without any knowledge of each of the attributes in them. b) To know which attribute you wish to link to from a related object, you will need to to take a look at its definition to get the key field. c) There could be more than one key field and sometimes the key of an entity could be a combination of several fields, which would not work with the current approach As a solution I would suggest just taking out every attribute in all the Association End lists. Question 3:
From the theoretical definition of inheritance, just by pointing to a class we cannot be sure to have access to its subclasses, only to its superclasses. As a solution I would propose to choice one of the following depending on what we are trying to describe:
a) Add ComputingService, StorageService, AdminDomain and UserDomain to the Association End list if we really would like to access attributes exclusively from those in the Location class, which results in more Foreign Key attributes. b) Remove them from the Inherited Association End list if we just want to have access to the attributes of the Service and Domain classes in the Location class. c) Just take out the Inherited Association End list and put in the Association End list all the concrete classes we want to point out. I would personally prefer this last option. In addition to the questions above, I have three proposals on how to implement the relationships and would appreciate some feedback on each of them and which one is prefered. 1) Use an 'EntityFK' attribute (same as GlueForeignKey used in GLUE 1.3) in every entity that has a relationship 2) Differentiate each final object in the relationship from its superclass point of view. E.g. LocationFKService 3) Differentiate each final object in the relationship to the very concrete classes we would like. E.g. LocationFKComputingService. I would personally prefer this last option. Also should we use 'FK' or 'ForeignKey'?. Regards, David -- David Horat Software Engineer specialized in Grid and Web technologies IT Department – Grid Deployment Group CERN – European Organization for Nuclear Research » Where the web was born Phone +41 22 76 77996 http://davidhorat.com/ http://cern.ch/horat http://www.linkedin.com/in/davidhorat
After looking at the example David sent, I have some suggestions on how we are doing the inheritance in LDAP. In the Location object for example, there is a mixture of Entity and Location Prefixes. I would propose that it would be better to have the same prefix. http://forge.ogf.org/svn/repos/glue/LDAP2/ldif/5-03-Location.ldif This could easily be done in the schema by specifying the attribute using the following. attributetype ( x.y.z. NAME ( 'LocationId' ) SUP EntityId ) However, for the ComputingServices I would prefer the names to be retained eg. ServiceId rather than ComputingServiceId. This would present and inconstancy in the way that we handle inheritance. My two questions would be does everyone agree with the above and if so how do we deal with this inconsistency? Laurence
Hi Laurence, On Monday 30 March 2009 13:39:27 Laurence Field wrote:
I would propose that it would be better to have the same prefix.
From http://forge.ogf.org/svn/repos/glue/LDAP2/ldif/5-03-Location.ldif
dn: EntityId=testLocation,o=grid objectClass: Location EntityId: testLocation EntityName: Headquarters [...] LocationAddress: 15700 103rd St. Suite 210 Lemont, IL 60439 USA LocationPlace: Lemont
So, using the above example, one would publish: dn: LocationId=testLocation,o=grid objectClass: Location LocationId: testLocation LocationName: Headquarters [...] LocationAddress: 15700 103rd St. Suite 210 Lemont, IL 60439 USA LocationPlace: Lemont I don't have a strong opinion on this. If you feel it's better to hide the inheritance (and it's feasible to do this) then OK with that.
However, for the ComputingServices I would prefer the names to be retained eg.
ServiceId rather than ComputingServiceId.
I'm not sure why ComputingService should be a special case here. Is it that ComputingServiceId is a bit of a mouthful?
This would present and inconstancy in the way that we handle inheritance. My two questions would be does everyone agree with the above and if so how do we deal with this inconsistency?
I would go for ComputingServiceId to be consistent with other published inhereted attributes, but I may have missed something. Cheers, Paul.
glue-wg-bounces@ogf.org [mailto:glue-wg-bounces@ogf.org] On Behalf Of David Horat said:
I am trying finalizing the initial draft of the LDAP implementation and have a few questions that need to be resolved before I can finish.
These were mostly addressed in other mails, but for completeness:
So in the Entity class, should Extension.LocalId be specified instead of Extension.Key?
The relations in the association end list are always specified with
Yes. the attribute they have to link with. (E.g. Service.ID). There are several reasons why this may not be a good idea. In GLUE the key for every object (except Extension) is *defined* to be the EntityID, so this is correct.
From the theoretical definition of inheritance, just by pointing to a class we cannot be sure to have access to its subclasses, only to its superclasses.
That isn't directly relevant in that LDAP queries are not object oriented and you do have access to everything. I.e. you can happily do a query like ldapsearch <blah> objectclass=Entity EntityID EndpointURL ComputingEndpointRunningJobs although I doubt that that particular query is very useful! Also many attributes are optional so code anyway can't assume their presence, whether they come from the main class or a derived class. However, this is related to why I think it would be a good idea to use real objectclass inheritance: it means you can do a query like ldapsearch <blah> objectclass=Endpoint EndpointURL to get the endpoint for every service, as opposed to ldapsearch <blah> (&(objectclass=Endpoint)(objectclass=ComputingEndpoint)(objectclass=Stor ageEndpoint)) EndpointURL or even ldapsearch <blah> (&(objectclass=Endpoint)(objectclass=ComputingEndpoint)(objectclass=Stor ageEndpoint)) EndpointURL ComputingEndpointURL StorageEndpointURL (and in the last case, consider the possible mess if I want to query with restrictions on HealthState, ServingState, QualityLevel, ...). If we do use inheritance it will also affect the way the keys work, i.e. if Endpoint has a key pointing to Service then it will automatically be inherited by ComputingEndpoint and StorageEndpoint. And I believe that Sergio said that we should not have "mixed" relations, i.e. that a ComputingService will only have relations to ComputingEndpoints and not to Endpoints, so there is then no need for any other kind of key.
In addition to the questions above, I have three proposals on how to implement the relationships and would appreciate some feedback on each of them and which one is prefered.
As above, it depends on the decision about inheritance, attribute naming and uniqueness of IDs.
Also should we use 'FK' or 'ForeignKey'?.
Out of those two it should be ForeignKey. However, an alternative would be to call them e.g. LocationServiceID which is more explicit. Stephen -- Scanned by iCritical.
Hi all, a quick note in general: I support everything Stephen has brought up in this forum - the important issues he flagged need to be resolved and I normally favor what Stephen proposes.
ldapsearch <blah> (&(objectclass=Endpoint)(objectclass=ComputingEndpoint)(objectclass=Stor ageEndpoint)) EndpointURL
or even
ldapsearch <blah> (&(objectclass=Endpoint)(objectclass=ComputingEndpoint)(objectclass=Stor ageEndpoint)) EndpointURL ComputingEndpointURL StorageEndpointURL
Those '&' should be '|' characters.
participants (5)
-
Burke, S (Stephen) -
David Horat -
Laurence Field -
Maarten Litmaath -
Paul Millar