[glue-wg] Physical Reresentational relationship?

owen.synge at desy.de owen.synge at desy.de
Wed Apr 9 08:18:58 CDT 2008


On Wed, 9 Apr 2008 12:26:11 +0100
"Burke, S (Stephen)" <S.Burke at rl.ac.uk> wrote:

> glue-wg-bounces at ogf.org 
> > [mailto:glue-wg-bounces at ogf.org] On Behalf Of owen.synge at desy.de said:
> > In other words why does the Glue schema have a service entity which is
> > mapped 1:1 with physical instance and not an VO-service entity?
> 
> As a minimum it saves publishing the same information many times over.
> Also some services are not VO-specific (e.g. BDII). Services do have the
> information on who is authorised to use them via the AccessPolicy, so
> there's nothing stopping you publishing separate services per VO, 

I fear you misunderstand. Nothing stopping you publishing separate
VO's, is an invalid argument when it comes to normalisation, which is
the Glue WG's task as I thought it, since Glue is developing a
relational schema. VO as an attribute seems to spread across many
entities, most services have an access control based by VO, some
services have VO as an attribute in other entities bound to services
providing other functions than access control.

> and
> indeed for most sites that's exactly what happens with the CE, i.e.
> there is one CE (queue) per VO - but it isn't very satisfactory because
> you end up with a huge number of queues.

Since with this change should eliminate all the other VO based
attributes, I see this as reducing the data required, not in instance
of services but in the entities and attributes associated with them, by
removing duplication of VO related entities and attributes. 

> On a more abstract level you could say that the publishing should be
> aligned with who "owns" the information. 

Ownership is not clearly defined in my mind, is a service for a VO or
provided by a site? Ownership could be either.

Personally I think the VO is a entity unfortunately cross site
relations are difficult to deploy and so we need to be pragmatic (hence
my suggestion of binding it to service), as it seems to be an attribute
currently distributed in many objects particularly in relation to
services I think adding it to Service makes some sense as then we may
have less in the way of entities/attribute.

to quote one point you made "Also intrinsically a VO is just
> one level in a UserDomain hierarchy, you can have groupings of VOs (all
> WLCG VOs, all GridPP VOs) and subgroups within VOs." 

Can you please explain what you mean here, Im still unsure its not
again a case of misunderstanding or me being silly and missing some
thing basic in your world view, a VO is a collection of users and so
for the purposes of this discussion and in the context of "3rd normal
form" hierarchies of user groupings are all the same thing, as they
resolve to a single entity which is by definition 1 or more users.

Am I wrong in believing Glue is a relational schema with the intention
of 3rd normal form, which will then be mapped to a LDAP XML and RDBMS
schema where performance optimisations will be added?

Regards

Owen



More information about the glue-wg mailing list