- glue-wg - lists.ogf.org

Glance Session
by Laurence Field 12 May '09

12 May '09

* URL: http://glue-wg.glance.net * Key: 1205

2 1

1st Draft of the GLUE 2.0 LDAP Implementation
by David Horat 12 May '09

12 May '09

Hello all, I just commited my first draft, which does not include any foreign keys. You can check it at our SVN: http://forge.ogf.org/svn/repos/glue/LDAP2/ Do not forget to read the README file first: http://forge.ogf.org/svn/repos/glue/LDAP2/README I am willing to have any kind of feedback. :) 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

4 6

LDAP and SQL Rederings
by Laurence Field 12 May '09

12 May '09

The initial drafts for the LDAP and SQL renderings are now available. The documents have been uploaded to the Grid Forge document repository. An updated Glue specification has also been uploaded which contains some changes that were made during the rendering process. The concrete renderings can be found in the subversion repository. SQL http://forge.ogf.org/svn/repos/glue/SQL/ LDAP http://forge.ogf.org/svn/repos/glue/LDAP2/ I will provisionally suggest that we should have a phone conference on Wednesday 6th of May at 15:00 to discus these initial drafts. Regards, Laurence and David

7 12

LDAP and SQL Rendering
by Laurence Field 11 May '09

11 May '09

Reminder Date: 12 May 2009 Time: 15:30 CET (conversion to other timezones) Duration: 1,5h Calling number: +41 22 76 77000 (ask to be connected to "GLUE Meeting")

1 0

LDAP and SQL Rederings
by Laurence Field 05 May '09

05 May '09

Due to popular demand, the phone conference will take place Tuesday May 12th at 15:30. Laurence

1 0

Question about ssociation end and inherited association end
by David Horat 17 Apr '09

17 Apr '09

In the GLUE Specification v. 2.0, page 9, there is the Location class, which has: Association.End: Service.ID Domain.ID Inherited association end: Extension.Key ComputingService.ID StorageService.ID AdminDomain.ID UserDomain.ID This seems to try to represent the fact that making a relationship with a class, you are also making it with all its subclasses. From the theoretical point of view, you can not imply that pointing to a class you have access to its subclasses, but just to its superclasses because of the definition of inheritance in the object oriente programming. Moreover, this is misleading because it depends on the implementation language whether you can cast a subclass of the current class without knowing exactly the current class. So I would propose two solutions here depending on what you wanted to describe: 1) Add ComputingService, StorageService, AdminDomain and UserDomain to the Association End list if you really want to access attributes exclusively from those in the Location class, which will add more Foreign Key attributes. 2) Just taking them out from the Inherited Association End list if in the Location class you just want to have access to the attributes of the Service and Domain classes. 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

3 4

Example LDIF
by Laurence Field 17 Apr '09

17 Apr '09

Hi Stephen et. al. As it seems that we are having some difficulty trying to go from the what is specified in the document to what we expect the LDIF to look like, I would suggest that we try to work backwards and as such have uploaded some initial examples of the LDIF to the SVN repository. http://forge.ogf.org/svn/repos/glue/LDAP2/examples/ These examples were created by taking the attributes and groupings from the document but using a pragmatic approach based on my experience with Glue 1.3 to create the resulting LDIF. If we can agree on what the resulting LDIF should look like then we can figure out the best way to go from the document to what we what which may result in us making some modifications to the specification. If there are any changes that you think should be done, i would suggest that you copy the file and rename to include your initials. We can then use diff to compare the files. Laurence

2 4

Finalizing the LDAP implementation of GLUE 2.0
by David Horat 17 Apr '09

17 Apr '09

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

5 5

Re: [glue-wg] Question about ssociation end and inheritedassociation end
by Burke, S (Stephen) 17 Apr '09

17 Apr '09

David Horat [mailto:david.horat@gmail.com] said: > IDs are unique globably as stated in page 8 of the GLUE 2.0 > Specifications. It has to be globally unique within its scope, but I'm not sure we ever discussed what that scope is, i.e. whether it's all objects or just all objects of the same type. For example, in glue 1.3 we have GlueClusterUniqueID and GlueSubClusterUniqueID which are both defined to be globally unique identifiers, but in most cases they are identical (the CE hostname). However, I'm inclined to agree that it should be unique among all objects. Stephen -- Scanned by iCritical.

1 0

Fwd: Question about ssociation end and inheritedassociation end
by David Horat 17 Apr '09

17 Apr '09

On Fri, Apr 17, 2009 at 12:23 PM, Burke, S (Stephen) <stephen.burke(a)stfc.ac.uk> wrote: > glue-wg-bounces(a)ogf.org >> [mailto:glue-wg-bounces@ogf.org] On Behalf Of Paul Millar said: >> Option 2) would allow publishing both Storage- and Computing- >> Service.ID >> values as LocationServiceID attributes; i.e., the following >> would be valid >> >> LocationServiceID=<StorageService.ID> >> LocationServiceID=<ComputingService.ID> >> LocationDomainID=<UserDomain.ID> >> LocationDomainID=<AdminDomain.ID> >> >> If this is all correct, I'd go for option 2) here. > > Note that this interacts with the way inheritance is done and the > question of whether IDs are globally unique. If there were separate > attributes called ComputingServiceID and StorageServiceID and they were > allowed to be identical then this scheme wouldn't work, but if every > object has a globally unique EntityID then it's OK. IDs are unique globably as stated in page 8 of the GLUE 2.0 Specifications. > > There is also an issue of whether you would want to know what kind of > object is being referred to - i.e. with this scheme you can't tell from > the Location object what kind of service/domain it relates to. On the > other hand I suspect that you would normally follow the reference the > other way round. True and I suspect the same. > > Stephen > -- > Scanned by iCritical. > _______________________________________________ > glue-wg mailing list > glue-wg(a)ogf.org > http://www.ogf.org/mailman/listinfo/glue-wg > -- David Horat Software Engineer – IT/GD – Grid Deployment Group CERN – European Organization for Nuclear Research » Where the web was born Address: 1211 Geneva - Switzerland, Office: 28/R-003 Phone +41 22 76 77996 Professional Web: http://cern.ch/horat Personal Web: http://davidhorat.com/ Profile: http://linkedin.com/in/davidhorat

1 0