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

[Sergio Andreozzi]

Hi Stephen,

Burke, S (Stephen) wrote:
> OK, I've started, but it's hard going! I'll just comment on the main
> entities for now and come back to the rest. One general comment is that
> I think most things could do with more detailed explanation; even I find
> it difficult to understand what some things mean, and I think someone
> new to this will get lost fairly quickly. 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

>   Page 5, I think there is still some problem with the multiplicities,
> or perhaps with my understanding of what they mean ... for example I can
> see "1"s near Endpoint, Share and Resource, and yet all of them also
> have *s - so they are optional in some directions and mandatory in
> others?! (Formally I think they should all be optional.)

they way you should think is:

- when I instantiate the endpoint, what associations must be instantiated?

e.g.: if I create an instance of endpoint, then it is mandatory to have 
  an association to service (and a service) but it is optional to have 
an assocation to share/accessPolicy/extension/activity


>   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).
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


example:

endpoint (*) ---- (1) service

when describing the endpoint, in the association end I have:

- Service.ID - 1 - An endpoint is part of a Service

that means: "when I instance an Endpoint, then this must have an 
assocation to a Service and the specific service is identified by the ID 
property"

> Entity: I'm not sure why the attributes are mandatory - also they are
> missing in all the other entities even though they all inherit from
> Entity! 


right, made them optional; before they were part of an independent class 
and optionality was expressed by the association; now these attributes 
are taken by inheritance and we need to make them optional

> In fact although the description says that everything inherits
> from Entity I suspect that excludes Extension? 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.

if Class A inherits from class B, then class A inherits all the class B 
attributes *plus* all its associations;

you'll see that all classes inheriting from class A, they have 
Extension.Key association end in the "inherited association end" table 
section

about Name in Entity, I'm not sure; I'd like to listen from other people 
as well; for OtherInfo, we could do that

> Extension: despite the statement at the start that everything must have
> an opaque ID Extension doesn't, the ID is the Key. I think that's a
> mistake - among other things you might have multiple instances of the
> same Key. That relates to another question which is why is the Value
> multiplicity *? I would suggest it should be 1 but you could have
> multiple instances for the same Key.

the extension is actually a special class; in fact it is the only one 
that does not inherits from 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

> Location: is missing OtherInfo, but it will get it automatically if it
> gets added to Entity.

ok, let's wait for other people opinion

> 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

> UserDomain: similarly I think UserManager and Member need more
> explanation and/or 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

> 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

> Also I think the enumerated Type list in the appendix is inadequate,

it is an open enumeration, therefore if values do not match, not problem 
to publish something extra; it is probably out of scope to provide a 
complete list;

> it's not really clear to me how this is supposed to work, given that
> every Service is supposed to have a unique Type (what about computing
> and storage services?!). Conversely many of the things which are listed
> (e.g. org.teragrid.gpfs) don't seem to represent things I would consider
> to be Services at all.

here we need some more experience I guess;

> 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

> 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

> 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

> For StartTime, is this different to Entity.CreationTime which
> should be inherited? 

CreationTime is a metadata about a representation of a GLUE class; it 
states when that data was created (basically when the info provider was run)

StartTime is the last start time of the endpoint

> 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

> 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 understand your point. You envision that start 
time is not published by the endpoint itself but by some other service;
I'll put a note in the doc

> 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

> Manager: I'm not sure why it needs a globally unique ID? 

about ID/LocalID probably we need more experience; apart a few cases, I 
don't know when to lean in one direction or in the other

> And again the
> Resource relation is mandatory which can't be right since the Resource
> itself is optional.

again, mandatory if you instantiate it; this is for consistency; an 
association does not leave alone

> 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?

> And again I don't think it needs a global ID. 

we need to better define when we want ID vs. LocalID

> Also there is no
> accompanying text, which should at the very least say that it's an
> abstract entity.

added


> Activity: it looks odd to have two identical lines for the
> Activity-Activity relation.

also to me... but I wanted to be consistent; since you can navigate from 
one end to another, then from the class you see two ends; unless we put 
directionality in the navigation (only from one end you can go to the 
other), then we need both in order to be consistent with the UML semantics

> Policy: I think we still have some problems with this ... for one thing
> I think the Rule has to have type "string", since we can't possibly
> specify all formats. And I'm not sure why the Rule is optional,
> shouldn't it be 1..*? 

right, changed

> Also I think we need to say something about the
> semantics in the case where you have multiple Policy objects, either
> with the same Scheme or with different Schemes. 

added a comment in the doc to be resolved


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


Cheers, Sergio


> Also the UserDomain
> relation should be * - the Rules may relate to several VOs, and
> conversely the UD object itself is optional. We also still need feedback
> on whether this can meet all the use cases - for EGEE I think we should
> be OK, but it's certainly a long way from being generic (DENY rules!).
> 
> AccessPolicy: One basic point is that it seems to me that APs should be
> related to Service as well as Endpoint, otherwise service discovery will
> be a lot more complex and messy than it is now. Also as I said above I
> think TrustedCA should be here.
> 
> MappingPolicy: I'm not clear if the concept of the Default mapping can
> actually work as stated. As mentioned above I don't think the relation
> to UD can be mandatory, it may well not be published, and while the
> Rules implicitly relate to a VO (or perhaps more than one) it may not be
> in any simple way, e.g. it may involve groups and roles. What exactly
> does it mean to say that there MUST be only one default MP per UD, in a
> way which is guaranted to be meaningful for all possible policy Schemes,
> all technologies, all service types, ...?
> 
>  OK, that's all the main entities, I'll get to the Computing part
> tomorrow.
> 
> Stephen


-- 
Sergio Andreozzi
INFN-CNAF,                    Tel: +39 051 609 2860
Viale Berti Pichat, 6/2       Fax: +39 051 609 2746
40126 Bologna (Italy)         Web: http://www.cnaf.infn.it/~andreozzi