Hi, On the Capacity issue, I think one source of confusion is that the current document shows a single Capacity with three lines linking it to share, MappingPolicy and Environment. That's misleading, because a single instance of Capacity can only ever be linked to one of those. For this kind of thing I think it would be better to have three separate Capacity boxes, each linked to only one other object, to make it clear that Capacity is an attribute of some other thing (the Capacity of this Share, etc). In fact the link to MappingPolicy shouldn't be there at all because it's another example of the same kind of thing: a Mapping Policy is an ACL, which has no independent existence, it's also just an attribute of something else (Share in this case). There are other things in the schema which behave like that, e.g. Location (you can only talk about the Location of some other thing). (You could say that UniqueID is an extreme example of this - many things have a UniqueID attribute, but by definition they are all different.) Stephen
Hi Stephen,
-----Original Message----- From: glue-wg-bounces@ogf.org [mailto:glue-wg-bounces@ogf.org] On Behalf Of Burke, S (Stephen) Sent: Mittwoch, 9. April 2008 23:01 To: glue-wg@ogf.org Subject: [glue-wg] Capacity representation
Hi,
On the Capacity issue, I think one source of confusion is that the current document shows a single Capacity with three lines linking it to share, MappingPolicy and Environment. That's misleading, because a single instance of Capacity can only ever be linked to one of those. For this kind of thing I think it would be better to have three separate Capacity boxes, each linked to only one other object, to make it clear that Capacity is an attribute of some other thing (the Capacity of this Share, etc). In fact the link to
Good point. If these links indeed are misleading then I would agree with your suggestion. Cheers, Felix
Burke, S (Stephen) wrote:
On the Capacity issue, I think one source of confusion is that the current document shows a single Capacity with three lines linking it to share, MappingPolicy and Environment. That's misleading, because a single instance of Capacity can only ever be linked to one of those. I totally agree. The current StorageCapacity was concieved mainly as a "define once" block for a set of attributes. The current UML implies that an instance of StorageCapacity can be contemporary linked to many different entities.
If we want to keep a common definition for the set of attributes which are in the storageCapacity class, then we could do it. But this should be treated as an abstract class from which other classes inherits the common attributes. I do not see really big advantages for this, therefore your proposal of three different/independent classes could be considered.
For this kind of thing I think it would be better to have three separate Capacity boxes, each linked to only one other object, to make it clear that Capacity is an attribute of some other thing (the Capacity of this Share, etc). In fact the link to MappingPolicy shouldn't be there at all because it's another example of the same kind of thing: a Mapping Policy is an ACL, which has no independent existence, it's also just an attribute of something else (Share in this case). There are other things in the schema which behave like that, e.g. Location (you can only talk about the Location of some other thing).
I understand that this was added to deal with the issue of a "Shared Share", i.e., what is the used size by a certain userDomain if different userDomains can access the same storageShare? how would you address this? - Sergio
(You could say that UniqueID is an extreme example of this - many things have a UniqueID attribute, but by definition they are all different.)
Stephen _______________________________________________ glue-wg mailing list glue-wg@ogf.org http://www.ogf.org/mailman/listinfo/glue-wg
-- 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
Hi Sergio, Stephen, On Wednesday 09 April 2008 17:44:30 Sergio Andreozzi wrote:
Burke, S (Stephen) wrote:
On the Capacity issue, I think one source of confusion is that the current document shows a single Capacity with three lines linking it to share, MappingPolicy and Environment. That's misleading, because a single instance of Capacity can only ever be linked to one of those.
Yes, absolutely, I think separating them would be much less confusing.
[...] If we want to keep a common definition for the set of attributes which are in the storageCapacity class, then we could do it. But this should be treated as an abstract class from which other classes inherits the common attributes.
OK. My understanding was that this subclassing was happening implicitly, but that it wasn't worth trying to express these subclasses as they hold the same (mostly optional) attributes (Of course, I may be alone with that understanding :-) If it looks cleared expressing the three different StorageCapacity classes (StorageShareCapacity, StorageEnvironmentCapacity, StorageMappingPolicyCapacity, I guess) as subclasses of some generic StorageCapacity class, then I'm happy with that. [...]
For this kind of thing I think it would be better to have three separate Capacity boxes, each linked to only one other object, to make it clear that Capacity is an attribute of some other thing (the Capacity of this Share, etc).
Yup, fair enough.
In fact the link to MappingPolicy shouldn't be there at all because it's another example of the same kind of thing: a Mapping Policy is an ACL, which has no independent existence, it's also just an attribute of something else (Share in this case). There are other things in the schema which behave like that, e.g. Location (you can only talk about the Location of some other thing).
I understand that this was added to deal with the issue of a "Shared Share", i.e., what is the used size by a certain userDomain if different userDomains can access the same storageShare? how would you address this?
Moreover, we have a use-case for doing VO-based accounting of StorageShares. I believe Nordogrid want to share StorageShares between VOs and account for their separate usage. In this case, the Mapping Policy is more than just an ACL. The MappingPolicy (i.e., the ability for a VO to use a StorageShare) has properties like usedSize. [No independent existence => should be an attribute] As a counter-example, the same is true for the CE-SE-Bind (in whatever form it might take). This leads no independent existence from the CE and SE it connects, yet is represented as an object. I would suggest that the CE-SE-Bind is represented as an object class because the link must have additional attributes (that qualify and describe the link) in order to satisfy the use-cases. Simply having an attribute "closeSE" in the CE objects is insufficient. So, I'd propose a rule-of-thumb: a conceptual link between two objects should be an attribute unless metadata must be recorded about the link. HTH, Paul.
Paul Millar [mailto:paul.millar@desy.de] said:
As a counter-example, the same is true for the CE-SE-Bind (in whatever form it might take). This leads no independent existence from the CE and SE it connects, yet is represented as an object.
I'll reply to the rest tomorrow, but just on this since I thought of another example: consider a coffee mug. That has a handle, and in principle I could consider it as a separate object (I could break it off), although for any practical purpose it's only useful when attached to the mug. Now consider that the mug has a capacity (I can put 300 ml of coffee in it). In that case it clearly makes no sense to consider the capacity as having an independent existence of any kind, there's no way to detach it from the mug. ("I've often seen a cat without a grin," thought Alice; "but a grin without a cat! It's the most curious thing I ever saw in all my life!") Similarly with the MappingPolicy: if the mug belongs to me that's an access rule, and although other things may belong to me the specific "instance" of belonging that applies to the mug is not transferrable or shareable - if I own two mugs and give one away it doesn't affect the other one (rules and capacities may be equal but that doesn't make them identical). In the case of the CESEBind there is something real underneath, some kind of network connection and/or firewall rules and/or policies about which protocols are allowed where. It might well be pointless to publish such information without relating it to a CE and an SE, but not nonsensical (indeed in principle it's interesting to know it for a UI). For that matter you could say the same about e.g. the AccessProtocol: we wouldn't publish one independently of an SE, and indeed we can't because it only has a LocalID. Nevertheless it does deserve to be an object and not just an attribute of something else because it describes a discrete part of the SE, much like the handle of a mug. Stephen
Hi Stephen, On Thursday 10 April 2008 00:32:47 Burke, S (Stephen) wrote:
Paul Millar [mailto:paul.millar@desy.de] said:
As a counter-example, the same is true for the CE-SE-Bind (in whatever form it might take). This leads no independent existence from the CE and SE it connects, yet is represented as an object.
I'll reply to the rest tomorrow, but just on this since I thought of another example: consider a coffee mug. That has a handle, and in principle I could consider it as a separate object (I could break it off), although for any practical purpose it's only useful when attached to the mug. Now consider that the mug has a capacity (I can put 300 ml of coffee in it). In that case it clearly makes no sense to consider the capacity as having an independent existence of any kind, there's no way to detach it from the mug. ("I've often seen a cat without a grin," thought Alice; "but a grin without a cat! It's the most curious thing I ever saw in all my life!")
I think this illustrates our different points of view. If I may summarise your position (please correct me if I'm wrong), you see object classes as necessarily being something concrete---something you can (in principle) hold in your hand (e.g. a cup), or that you could separate and similarly hold in your hand. From your point-of-view, a smile cannot be held in a hand, so necessarily cannot be an object. If so, I see I have a different point-of-view. For me, an object class is any well-defined logical concept defined only by its relationships with other object classes and the attributes it may have (there are probably some stronger statements one can make). An object class may (or might not) have an independent life from other logically defined concepts. For example, a smile, whilst having no independent life from the mouth it describes, is still a pretty well defined concept in most peoples heads. For example: http://images.google.co.uk/images?um=1&hl=en&q=smile&btnG=Search+Images or, perhaps better results with ESP: http://www.captcha.net/esp-search.html In a "hand wavy" way, the fact that Google or ESP can find a bunch of images that people can identify something that's the same ("yep, they're all smiling") suggests that there is some common concept that they all have. There are then two questions: a. do we want to model this common feature? b. how do we best model this feature? If the answer to a. is "yes", then the question is how best to model it. If there is no metadata associated with the concept (someone is either smiling or they're not), then it could be as an attribute or an attribute value in an enumeration. For example: Face: smiling <boolean> := true {or false} or Face: mouth-posture <open enumeration> := smiling {or shocked, upset, ...} If there is metadata to be recorded and we want to keep this as an attribute, then this metadata must either be encoded within the attribute value (embedding the metadata within the name) or be encoded as associated attributes; either: Face: mouth-posture <open enumeration> := smiling-smirk, smiling-broad, smiling-faint, ... or Face: mouth-posture <open enumeration> := smiling smiling-type <open enumeration> := smirk {or broad, faint, ...} respectively. (There may be other ways of recording the information as attributes, but I can't think of them just now.) Neither of these solutions is very satisfactory, as it requires the client to understand the additional semantics; e.g., if you see "smiling-", split at the "-" and treat the second part as a type value; or, if you see "smiling" look for the smiling-type attribute, ignore it otherwise. I would say that the natural solution is to express the information as a new object class, subclassing from a generic type, with the attributes you need to record. Face: mouth-posture <mouthPostureType> := smileMouth smileMouth extends mouthPostureType: smiling-type <open enumeration> := smirk {or broad, faint, ...} The same information is recorded, but here the structure is made explicit. One of the goals of modelling is to make community knowledge explicit, so writing clients that consume this information is easy. This is how I see the transition from Glue-1.3 to Glue-2.0: GLUE-2.0 should (if feasible) make explicit what was previously implicit knowledge (such as, custodial-online, means D1T1, means guaranteed to be stored on disk and tape).
Similarly with the MappingPolicy: if the mug belongs to me that's an access rule, and although other things may belong to me the specific "instance" of belonging that applies to the mug is not transferrable or shareable
OK, counter example. When you buy the mug at the shop, they give you a till receipt (typically). That receipt proves that you've bought the mug in the store. If you are challenged whilst leaving the shop, you can produce the receipt, proving you've bought that mug. So the receipt is a concrete object that represents your ownership of that mug. Your ownership is transferable (you give the receipt and mug to someone else whilst in the shop, they walk out with the mug) and sharable (a group of people all club together to pay for the mug, they sign a document saying they have part-share of the ownership, the two documents are stabled together).
if I own two mugs and give one away it doesn't affect the other one
True, no one suggests that it is should affect the other.
(rules and capacities may be equal but that doesn't make them identical).
True, again no one is suggesting that two objects with equal properties are the same thing.
In the case of the CESEBind there is something real underneath, some kind of network connection and/or firewall rules and/or policies about which protocols are allowed where.
(I fear you're grasping at straws here ;-) Network infrastructure (networks, routers, firewalls, etc...) connects everything together, this isn't special about CEs and SEs that they require network connectivity.
It might well be pointless to publish [network/firewall/policies] without relating it to a CE and an SE, but not nonsensical (indeed in principle it's interesting to know it for a UI).
Yes, indeed. In effect the CE-SE bind is some summary information, giving a brief describion of the "connectivity" between a CE and an SE. It summaries the network topology, configuration and policies that would be (potentially) too complex to represent explicitly. But, going back to your original point: I can't hold a CE-SE bind in my hand, but I can hold a network cable in my hand, likewise a switch, router (if not too heavy). If I followed your argument to its logical conclusion (and if I understand it correctly), I should replace CE-SE bind objects with a description of the networking (routers, switches, cabling) and allow jobs to deduce which SE they should use.
For that matter you could say the same about e.g. the AccessProtocol: we wouldn't publish one independently of an SE, and indeed we can't because it only has a LocalID. Nevertheless it does deserve to be an object and not just an attribute of something else because it describes a discrete part of the SE, much like the handle of a mug.
OK, I accept the analogy: comparing an AccessProtocol to a handle of a mug (more or less) works, although there's a few questions about the similarity of snapping off the handle vs. "detaching" an AccessProtocol. But, this then leads to the question: what is it about the handle of a mug that means you're happy describing it with an object? Sorry for the noise, but I don't understand! Cheers, Paul.
Paul Millar [mailto:paul.millar@desy.de] said:
I think this illustrates our different points of view. If I may summarise your position (please correct me if I'm wrong), you see object classes as necessarily being something concrete---something you can (in principle) hold in your hand (e.g. a cup), or that you could separate and similarly hold in your hand. From your point-of-view, a smile cannot be held in a hand, so necessarily cannot be an object.
Well, not quite - the question for me is whether you could have a specific instance of the thing which is detached from the parent. Things you can hold in your hand will obviously fall into that category, but more abstract things might as well - indeed a VO is something like that, the atlas VO is a rather abstract idea but still has a definite existence independent of its members and is definitely not the same VO as cms. Maybe there are contexts in which a smile could be separately identifiable, e.g. clowns "register" their facial design, or there might be a specific "style" which would allow you to say that two people have the same smile (identical rather than equal).
If so, I see I have a different point-of-view. For me, an object class is any well-defined logical concept defined only by its relationships with other object classes and the attributes it may have (there are probably some stronger statements one can make).
But what about *instances* of the class? Some classes can have definite, identifiable instances and some can't. (You can also get into metaphysics here, e.g. are all instances of the integer "3" identical? :) I did a course on python last week and the way in which it treats things as identical or not was the bit I found hardest to grasp, e.g.:
a=[[0]*4]*4 a[0][0]=1 a [[1, 0, 0, 0], [1, 0, 0, 0], [1, 0, 0, 0], [1, 0, 0, 0]]
So four out of the 16 elements are identical ...
http://images.google.co.uk/images?um=1&hl=en&q=smile&btnG=Sear ch+Images
So which of those share the same *instance* of a smile? Compare with, say, photographs of cars, where it would make sense to say that all cars of a specific model share a single "model" instance, even though that's also an abstract concept.
OK, counter example. When you buy the mug at the shop, they give you a till receipt (typically).
Yes, and that would be a different context. In fact I was going to give the alternative example of rental, where you have a rental contract that defines the relationship, so it does make sense to ask which things belong to which contract. For ownership the contract normally only applies at the point of purchase, so in most contexts it isn't relevant to ask whether things were purchased together or from the same supplier - but if that's the context you're working in then indeed the relationship may become concrete and you could talk about a specific instance of it (these three books belong to me by virtue of this specific invoice from amazon).
Your ownership is transferable (you give the receipt and mug to someone else whilst in the shop, they walk out with the mug)
Possibly diverging too far from the subject, but I don't agree - the shop sold it to you regardless of the fact that you give the mug and receipt to someone else, so the ownership *instance* doesn't transfer even though the ownership does (it now derives from an implicit contract with you). Conversely, if someone steals the mug and receipt that doesn't give them legal ownership.
and sharable (a group of people all club together to pay for the mug, they sign a document saying they have part-share of the ownership, the two documents are stabled together).
Then you create a new object (the club) which uniquely owns the mug and which has the people as members.
if I own two mugs and give one away it doesn't affect the other one
True, no one suggests that it is should affect the other.
As I say, if you consider object instances (which we obviously will when we implement it) it's a vital distinction - if two objects share the same instance of another object then one *will* affect the other (see the python example above). If I rent both mugs under the same contract and the contract gets terminated then I do lose both together.
(I fear you're grasping at straws here ;-) Network infrastructure (networks, routers, firewalls, etc...) connects everything together, this isn't special about CEs and SEs that they require network connectivity.
What's special is that the network path allows e.g. dcap to work (no firewall blocks) and has sufficient bandwidth to support it. That's a well-defined feature of the path, it applies to any connection between the two domains and a single change (e.g. a firewall block in the middle) would block all of them. Hence it does make sense to say that there is a single instance of the dcap "binding" over that path, independently of what happens to be at either end.
OK, I accept the analogy: comparing an AccessProtocol to a handle of a mug (more or less) works, although there's a few questions about the similarity of snapping off the handle vs. "detaching" an AccessProtocol.
Not so much, you could turn off the SRM but leave the gridftp server running (and obviously vice versa).
But, this then leads to the question: what is it about the handle of a mug that means you're happy describing it with an object?
Intrinsically it's probably that I could give a name (UniqueID) to that specific instance - for the capacity I can't, it has no identity of its own. Stephen
participants (4)
-
Burke, S (Stephen) -
Felix Nikolaus Ehm -
Paul Millar -
Sergio Andreozzi