[glue-wg] GLUE 2.0 Specification - draft 41 - Working Group LastCall

[Paul Millar]

Hi Sergio, Stephen,

On Wednesday 14 May 2008 20:03:46 Sergio Andreozzi wrote:
> Burke, S (Stephen) wrote:
> > Can we give some examples in the text?
>
> in general normative documents do not have examples, but I agree that we
> should add more descriptive text. We may also put some examples and
> stating that they are non normative

I agree that one should be careful about introducing examples in normative 
documents; specifically, be careful that one isn't relying on the examples to 
explain anything as the normative sections should be sufficient to completely 
specify expected behaviour.

However, Stephen is right, I think some examples would help.


> >   All the definitions have a section labelled "Association End" - what
> > does "End" mean there?
>
> it is borrowed by the UML world. Have a look at Section 8 (Template).

Hmmm, perhaps this information would be better nearer the beginning of the 
document.  In my experience, it's common to have typographical conventions 
declared pretty early on in a document.


> Here is a better description:
>
> given the class X, such a class has an associated table (in the GLUE
> doc). In this table, the Association End section lists all the
> associations that starts from this class. What is described is the
> "other side" of the association (association end) in terms of:
> - what class is associated
> - what is the key attribute
> - what is the multiplicity (when I instantiate X, how many instances of
> the associated class can be associated to X via that association?)
> - description of the association from the viewpoint of X

It might be an idea to also include a one-line definition what is meant by an 
association: connects two entities, is uni-directional (but may have a 
reciprocal association), is defined with same multiplicity options as 
attributes, etc.


> > In fact although the description says that everything inherits
> > from Entity I suspect that excludes Extension?

Yes, I believe the statement "everything inherits from Entity" is currently 
wrong.


> > Also I'd be inclined to add Name and OtherInfo to Entity - at the moment
> > not everything has a Name but I don't think it does much harm to include
> > it. 
>
> about Name in Entity, I'm not sure; I'd like to listen from other people
> as well;

Name has different multiplicity in different entities.  Apart from the few 
entities that don't have a Name property, for Location it's a required 
property.

If we allowed Name to be optional for Location then I think Name could (and 
should) go into Entity.

> for OtherInfo, we could do that 

Yes, putting OtherInfo into Entity would simply things.  There are a few 
entities that don't have OtherInfo, but these omissions look like a mistakes.

[...]
> the extension is actually a special class; in fact it is the only one
> that does not inherits from Entity.

Is there a reason for this?  If the attributes in Entity are optional (as is 
agreed elsewhere, I believe), then Extension could extend Entity.


> I agree with your proposal; I can make the following changes:
> - Rename Key to ID (unless we want ID, Key, Value)
> - Value - multi = 1


Actually, I was going to argue against this change (sorry Stephen): a single 
key with multiple values may be logically distinguishable from multiple 
attributes with the same key (although LDAP doesn't allow this distinction, 
XML does).

In fact, if anything, I would change the multiplicity of Value to (1..*).  If 
Value isn't specified, the Key could be represented as an OtherInfo attribute 
in the corresponding Glue entity.



> > Location: is missing OtherInfo, but it will get it automatically if it
> > gets added to Entity.
>> ok, let's wait for other people opinion

My vote is for adding OtherInfo to Entity.


> > AdminDomain: I think Owner needs to be defined better.
>
> what about:
> 
> Identification of the person or legal entity which pays for the services
> and resources

The attribute has (*) mult., so "person" should be "people", also a Resource 
is made available through a Service (I think one cannot provide a service 
without also providing the necessary resources underneath).

So, how about:

Identification of the people or legal entities that pay for the services.


> > UserDomain: similarly I think UserManager and Member need more
> > explanation and/or examples.

I too feel these attributes are not currently specified well enough.

Please improve the explanation, though; examples are useful, but I'd prefer 
effort went into providing better explanations than went into providing 
examples.



> > Also it's not clear if what's there can 
> > work - for example if UserManager is supposed to be a VOMS URL the
> > scheme would just be https, so how can you tell that it's VOMS and not
> > something else? Probably it would need some kind of Type attribute.
>
> the UserManager is actually an Endpoint.ID and not the URL; therefore it
> identifies an endpoint class instance with all the info

So UserManager should be an association rather than a property, right?


> > Service: it's not entirely obvious to me why Capability is mandatory.
>
> let's say that you want to search for all job execution services
> regardless their interface/implementation; you can search for services
> having Service.Capability = executionmanagement.jobexecution	(capacity
> of executing a job or set of jobs)
>
> it is needed if you want to search for Grid capability regardless the
> middleware interface/implementation; a different level of abstraction

This is laudable, but a couple of points:

  1.  I believe usage (in terms of specialising some abstract entity) in 
Glue-2.0 is described by subclassing:  a job-execution service is a 
ComputingService, so this field is of limited use in this case.  From an OOP 
analogue, requiring users to submit information of a prescribed form is 
usually indicative of a problem with the class hierarchy.

  Perhaps this could be fixed by making Service an abstract entity and 
creating a new concrete entity (lets call it "OtherService" for now).  
OtherService instances describe services that one would otherwise be unable 
to advertise correctly.  The OGSA Capacity attribute would make more sense 
for these entities (IMHO).

  2. Do these OGSA terms have specific semantics?  In particular, I'm 
concerned that a client, on discovering something advertising itself with a 
specific Capacity_t value (e.g., "security.accounting") will attempt to 
interact with that service using whatever OGSA services are defined for that 
Capability_t value.

  Since a Service might provide no OGSA compliant service, yet still be 
(meaningfully) advertised within GLUE, perhaps the multiplicity should be 
(0..*)


> > Endpoint: again I wonder why Capability is mandatory.
>
> I think that in the Grid context, there should be an effort of
> classifying services and endpoints in terms of the conceptual capability
> that is provided

Again, some comment as with Service: there seems a confusion between the 
abstract concept of a end-point (that all end-points inherit from) and 
an "OtherEndpoint", that describes end-points that are not one of the 
specific End-point subclasses.
(my 2c worth)


> > And I don't
> > understand why or how Type and Version are combined as a single
> > Interface URI: at the very least this needs *much* more explanation
> > since it's absolutely vital to using the endpoints! And the Type list
> > needs to be enumerated (as it is now). Basically I don't understand why
> > we haven't kept the Type and Version as we have them in 1.3.
>
> this emerged during the revision process with Balazs; one of the most
> wanted query pattern is: I want to search for an endpoint complying with
> an interface name an version, plus some extensions as well.
>
> E.g.: ARC implements BES 1.0 + a number of extensions; how do you search
> for them?
>
> Interface = urn:ogf:bes:1.0 and InterfaceExtension = urn:arc:bes++:1.0
> and InterfaceExtension = urn:ogf:hpc:1.0
>
> the problem sits mainly in the extensions; by coupling the name and
> version into one attributes, we can maintain simple properties

Could the documentation be updated to say that Interface should (must?) be a 
URN that encodes the type and version of the interface.  Leaving it 
as "Type=URI" is potentially confusing.


> > For QualityLevel, how do the Endpoint QLs relate to the one in the parent
> > Service?
>
> we discussed this and found no good answer so far, therefore we do not
> enforce relationship and leave up to who will configure the service;
> after some experience we may better rule it

It might help to include a comment to this effect within the property's 
definition.

[...]
> > I still think that TrustedCA belongs in
> > AccessPolicy and not Endpoint - if we can't figure out how to fit it in
> > there it probably means that we still don't have a good enough
> > definition of the AP object.
>
> I'm not strong on this; TrustedCA is somewhat independent from the
> policies you set (thought it is related); and also, if you represent the
> same policy using different languages, than you have to replicate it
> when putting the attribute in MappingPolicy

I'm have no strong opinion, but feel I should point out that it might also be 
common across all Endpoints, so (in effect) a property of the Service.  In 
practise, with Globus/LCG/gLite/... software stack, trust is asserted by 
include the CA certificate in /etc/grid-security/certificates/ (or equiv. for 
Tomcat), so is often common across all Services on the same host.  The trust 
is often common across a Site (since CA certs are often installed 
automatically to provide consistent service across the site).

Perhaps it should live as a separate entity that objects can link against; but 
I think Stephen's right, the confusion probably stems from not having a good 
enough understanding of entities (and AP in particular).

In the meantime having it optionally within the Endpoint seems a reasonable 
compromise.

> > And I still think the Downtime attributes
> > should be in a separate object, to me it makes no sense to put them
> > there - among other things, if the service is down the Endpoint will
> > probably not be published so you won't be able to read the Downtime
> > information.
>
> this was done also for simplifying the query and because the
> relationship is 1--1.

I don't think the relationship is necessarily 1:1.  A site might choose to 
publish a small calendar of the next few scheduled down-times (e.g., it's a 
Windows NT box that must be rebooted every weekend).

[...]
> > Share: the Endpoint and Resource relations are marked as mandatory,
> > which doesn't seem right since the objects are supposed to be optional.
>
> that means, if you instantiate a share, than you must instantiate an
> association to an existing resource and and existing endpoint;
>
> in this particular case, anyway, this is a kind of "pattern"; share and
> reource are abstract (and so the relationships) which means not meant to
> be instantiated, but subclussed

True, but the issue remains: (subclasses of) Endpoints and (subclasses of) 
Resources are meant to be optional for (subclasses of) Share.  For example, 
describing a StorageShare without a corresponding StorageResource is suppose 
to be supported.


> > Resource: as above, the description and the relations say that
> > Endpoints, Shares and Managers are mandatory, which doesn't seem right.
>
> here you raise a new possible use case: do we want to allow to publish a
> service with no endpoint and no share, but a manager and a resource?
>
> given the assocations multiplicity, at the moment we can have:
>
> 1. Service
> 2. Service + Endpoint
> 3. Service + Endpoing + Manager + Resource
>
> do we need different patterns to be described?

I think either:
  Service + Endpoint + Share
or 
  Service + Endpoint + Share + Manager

was one option we wanted to retain, but I'm hoping others can comment further.


> now I've to go... will answer to remaining part later. I've put the
> temporary new version (with track changes enabled) here:
>
> http://forge.ogf.org/sf/go/doc15213

Gridforge seems down just now :-(

Cheers,

Paul.