Difference between revisions of "Scope Management"

From GCube System
Jump to: navigation, search
(→‎Scope Rules)
(→‎Scoping Rules for gCube Hosting Nodes)
 
(80 intermediate revisions by 3 users not shown)
Line 1: Line 1:
−
[coming soon]
 
−
 
 
== What's in Scope? ==
 
== What's in Scope? ==
−
Any gCube resource may only be shared within one or more scopes in the infrastructure on which it is deployed.
 
−
Outside its scopes, in particular, the resource can neither be discovered nor used.
 
  
−
''' Scope is a multi-valued property of all gCube resources.'''
+
In gCube, a resource may only be shared within one or more scopes. Outside these, the resource can neither be discovered nor used.
 +
 
 +
A Running Instance, in particular, may operate in different scopes at different times. For this to happen, clients must specify
 +
a scope when contacting the instance. Similarly, any state which the instance might create must retain the scope of the call which triggered the creation.
 +
 
 +
It is so that resources, WS-Resources, and calls are all scoped in gCube.
  
 
== Modelling Scope ==
 
== Modelling Scope ==
−
Three levels of scope may be assigned to a resource: a ''gCube Infrastructure'' (GI), a ''Virtual Organisation'' (VO), or a ''Virtual Research Environment'' (VRE).
 
  
−
The levels are hierarchically ordered: GIs are ''above'' VOs and VREs are ''below'' VOs.  
+
In gCube, there are three levels of scope: the ''Infrastructure'', the ''Virtual Organization'' (VO), and the ''Virtual Research Environment'' (VRE).
 +
 
 +
The levels are hierarchically related: the VRE groups resources which satisfy the requirements of a particular application, the VO groups resources which support the operation of one or more VREs, and the infrastructure groups resources which support the operation of one or more VOs. In particular, a VRE exists only in the context of a VO which in turn exists in the context of some infrastructure.  Informally, we say that the VRE is below the VO and that the infrastructure is above it.
 +
 
 +
We use expressions of the form <code>/A/B/C</code> to denote a VRE <code>C</code> below a VO <code>B</code> below an infrastructure <code>A</code>.
 +
Informally, <code>/A/B/C</code> may be thought of as the fully qualified name of <code>C</code>.
 +
More formally, we use the following grammar for scope expressions:
  
−
We follow a grammar to denote scopes in a way which explicitates their hierarchical relationships:
 
 
<pre>
 
<pre>
−
SCOPE : = = GI | VO | VRE
+
SCOPE ::= I | VO | VRE
−
GI :== /l
+
I ::= /NAME
−
VO :== GI/l
+
VO ::= I/NAME
−
VRE :== VO/l
+
VRE ::= VO/NAME
 +
NAME ::= <a conventional label>
 
</pre>
 
</pre>
−
where ''l'' ranges over an alphabet of labels.
 
  
−
For convenience, we write '''S1 below S2''' to indicate that S1 and S2 denote the scope or that S1 is directly or indirectly below S2.  
+
In gCF, scope expressions can be conveniently thought as serialisations of <code>GCUBEScope</code> objects.  
−
Similarly, we write  '''S1 above S2''' to indicate that S1 and S2 denote the scope or that S1 is directly or indirectly above S2.
+
''to be continued...''
−
 
+
−
We model '''scoping''' as a binary relationship between resource and scopes.
+
−
We write '''R in S''' to denote a pair (R,S) of a resource R and a scope S in the scoping relationship.
+
  
 
== Scope Rules ==
 
== Scope Rules ==
  
−
Scoping is constrained by a number of '''scope rules'''.
+
Scoping in gCube is rooted on a first, basic rule: 
  
−
Scope rules are specific to resource types. A default rule, however, applies to all of them:
+
            <pre>R1) a resource in the scope of a VO is also in the scope of the VREs below.</pre>
  
−
Let VRE range offer virtual research environments, R be a resource and VO virtual organisation.
+
So, a resource in <code>/A/B</code> is also in <code>/A/B/C</code> but not necessarily in <code>/A</code> or in <code>/A/D</code>.
  
−
''DEF) if R is shared in a VOs then it is also shared in VREs below:'' '''R in VO => for each VRE in VO. R in VRE'''
+
R1 captures the intuition that resources shared by a Virtual Organization are immediately available to all its applications. As noted above, these resources are most often dedicated to the management of the VREs: gCube Hosting Nodes and Running Instances of Core services have typical example of VO-level resources.
  
−
* NB: The opposite does not always hold: depending on resource type, a resource may be shared in a VRE but not in the VO above.
+
'''Note:''' The converse of R1 does not hold: a resource shared in a VRE may be dedicated to it. That is, it ''may'' not be shared in the VO above (and, for ''R1)'', in the other VREs of that same VO).
−
* NB: Most definitely, a resource shared in a GI is not automatically shared in the VOs. For this to happen, the resource may have to explicitly join a VO.
+
 
 +
'''Note:''' R1 does not extend to infrastructure scope: a resource in that scope ''may'' not be automatically shared in the VOs below. This captures the intuition that most resources with infrastructure scope manage VOs in a way which is transparent to them, 'in the background'.
 +
 
 +
We now consider additional rules which restrict, widen, or simply complement R1 in reflection of the semantics and pragmatics of individual resources types.
  
 
=== Scoping Rules for gCube Hosting Nodes ===
 
=== Scoping Rules for gCube Hosting Nodes ===
  
−
Let GI range over gCube Infrastructures and GHN be a hosting node.
+
Sharing in gCube starts with GHNs, the main fabric of the infrastructure. GHNs are first pooled at the infrastructure scope and, in accordance with R1), must be explicitly ''joined'' to one ore more VOs. The rules which govern the sharing of GHNs are constrained by the following rules:
  
−
''GHN1) GHN may only be shared in one infrastructure:'' '''exist GI. GHN in GI and (GHN in S => S below GI)'''   
+
            <pre>GHN1) all the scopes of a GHN must be rooted in the same infrastructure.</pre>
  
−
''GHN2) if a GHN is shared in a scope is also shared above it:'' '''GHN in S =>  for each S' above S. GHN in S''''   
+
            <pre>GHN2) a GHN in a given scope is also in the scopes above.</pre>
  
−
* NB: ''GHN2)'' proves that the converse of ''DEF)'' hold for GHNs: A GHN cannot be shared in VRE(VO) if it is not shared also in the VO(GI) above.
+
GHN1 rules assert that GHNs cannot be shared across infrastructures (though the machine on which they run can of course).  GHN2 states that the converse of R1 holds for GHNs and is mainly an implication of infrastructure monitoring requirements.
  
−
gCore implications:
+
'''Note:''' gCore allows site administrators to configure their GHN to start in zero ore more VOs. gCF enforces GHN1 by making sure that the ''start VOs'' are all rooted in the same infrastructure. It then uses GHN2 to optimise scope management (keeps rack only of VO scopes).
−
* ''DEF)'' + ''GHN2)'' => model GHN scope as a list of one GI and zero or more VOs.
+
−
* on add, enforce ''GHN1)'' and retain only VO from VRE scopes (GCUBEHostingNode)
+
−
* on remove, prevent removal of GI if attempted (GCUBEHostingNode)
+
−
* on bootstrap, require configuration of single GI and allow zero ore more start VOs (GHNBuilder)
+
  
 
=== Scoping Rules for gCube Services ===
 
=== Scoping Rules for gCube Services ===
  
 
Let SV be a gCube Service.
 
Let SV be a gCube Service.
 +
<pre>
 +
SV1) if SV is shared in a scope it is also shared below it: SV in S => for each S' in S. R in S'
 +
</pre>
 +
'''Note:''' This extends R1) to infrastructure-level scope make scoping simplest for services.
  
−
''SV1)'' if SV is shared in a scope it is also shared below it: '''SV in S => for each S' in S. R in S''''
+
gCore implications: none special, scopes are immutable for services (i.e. for the ones already deployed).
−
 
+
−
* NB: This extends ''DEF)'' to infrastructure-level scope make scoping simplest for services.
+
−
 
+
−
gCore specifications: none special, scopes are immutable for services (i.e. for the ones already deployed).
+
  
 
=== Scoping Rules for Running Instances (RIs) of gCube services ===
 
=== Scoping Rules for Running Instances (RIs) of gCube services ===
Line 72: Line 73:
 
   
 
   
 
Let SV(RI) and GHN(RI) denote, respectively, the service of a RI and the GHN on which the RI is deployed.
 
Let SV(RI) and GHN(RI) denote, respectively, the service of a RI and the GHN on which the RI is deployed.
 +
<pre>
 +
RI1) RI can only be shared where its GHN and service can: RI in S => GHN(RI) in S and SV(RI) in S
 +
</pre>
  
−
''RI1) RI can only be shared where its GHN and service can:'' '''RI in S => GHN(RI) in S''' and '''SV(RI) in S'''
+
'''Note:''' The opposite of RI1) does not hold: a RI is not necessarily shared wherever its GHN and its service are.
−
 
+
−
* NB: The opposite of ''RI1)'' does not hold: a RI is not necessarily shared wherever its GHN and its service are.
+
  
 
gCore implications:  
 
gCore implications:  
  
−
* on add, enforce ''RI1)'' (ServiceContext)
+
* on add, enforce RI1) (ServiceContext)
 
* on startup,
 
* on startup,
 
** generic service: subscribe consumer for GHN remove scope events only (ServiceContext) => remove all RI scopes contained in those removed from the GHN (consumer).
 
** generic service: subscribe consumer for GHN remove scope events only (ServiceContext) => remove all RI scopes contained in those removed from the GHN (consumer).
Line 93: Line 95:
 
Let WSR denote a WS-Resource and RI(WSR) the RI through which has generated WSR.
 
Let WSR denote a WS-Resource and RI(WSR) the RI through which has generated WSR.
  
−
''WSR1) WSR can only be shared where its RI can:'' '''WSR in S => RI(WSR) in S''' 
+
<pre>
 +
WSR1) WSR can only be shared where its RI can: WSR in S => RI(WSR) in S  
 +
</pre>
  
−
* NB: The opposite of RI1 does not hold: a RI is not necessarily shared wherever its GHN and its service are.
+
'''Note:''' The opposite of RI1) does not hold: a RI is not necessarily shared wherever its GHN and its service are.
  
 
gCore implications:  
 
gCore implications:  
  
−
* on creation, enforce ''WSR1)'' (GCUBEHandler)
+
* on creation, enforce WSR1) (GCUBEHandler)
 
* on remove, remove from all WS-Resource which have been created by some stateful-port-type of the RI below the removed RI scope;
 
* on remove, remove from all WS-Resource which have been created by some stateful-port-type of the RI below the removed RI scope;
 
** due to persistence, cannot be easily performed locally, use instead queries to the IS
 
** due to persistence, cannot be easily performed locally, use instead queries to the IS
 +
 +
== Configuring scope (Static scope) ==
 +
Static scope applies only for those resources that can be manually created by humans. For such gCube resources, a scope S can be statically (i.e. manually) configured and changed through their appropriate configuration files.
 +
 +
=== Static scope for gCube Hosting Nodes  ===
 +
A gHN is always manually deployed, therefore a static scope configuration is always needed. Such a configuration is expressed with two parameters in the $GLOBUS_LOCATION/config/GHNConfig.xml file.
 +
 +
* ''infrastructure'' reports the GI the gHN joins (and it can be one and only one, as for ''GHN1)''. In the following example, the gHN is configured to join the ''/gcube'' infrastructure:
 +
 +
<pre>
 +
<environment
 +
        name="infrastructure"
 +
        value="gcube"
 +
        type="java.lang.String"
 +
        override="false" />
 +
 +
</pre>
 +
 +
* ''startScope'' is a comma-separated list of VOs the gHN joins. These VOs has to be below the infrastructure (as for ''GHN2)''), otherwise they are ignored. The list of VOs can be an empty list. In the following example, the gHN is configured to join both the ''/gcube/devsec'' and the ''/gcube/testing'' VO:
 +
 +
<pre>
 +
<environment
 +
        name="startScopes"
 +
        value="devsec,testing"
 +
        type="java.lang.String"
 +
        override="false" />
 +
</pre>
 +
 +
=== Static scope for gCube Services ===
 +
A gCube service has always only a static scope, specified at service registration time in the Software Repository service.
 +
 +
=== Static scope for Running Instances (RIs) of gCube services ===
 +
 +
Static scope for RIs has a mean only for those that are manually deployed. A RI can be configured to join one or more VOs and/or VREs with a comma-separated list. Due to ''RI1)'', the VOs has to be a subset of the VOs to which the GHN(RI) is joined to and the VREs has to be below the VOs to which the GHN(RI) is joined to.
 +
 +
In order to specify the static scope of a RI, insert a ''startScopes'' parameter in the service context section of the JNDI's RI with the fully qualified name of the scope as follows:
 +
 +
<pre>
 +
<service name="gcube/common/vremanagement/Deployer">
 +
 +
<environment
 +
name="configDir"
 +
value="@config.dir@"
 +
type="java.lang.String"
 +
override="false" />
 +
 +
<environment
 +
name="securityManagerClass"
 +
value="org.gcube.common.core.security.GCUBESimpleServiceSecurityManager"
 +
type="java.lang.String"
 +
override="false" />
 +
 +
<environment
 +
name="startScopes"
 +
value="/gcube/devsec/EM,/gcube/testing/test1"
 +
type="java.lang.String"
 +
override="false" />
 +
 +
</service>
 +
</pre>
 +
 +
'''Note:''' The ''startScopes'' parameter is optional: if it is not used, the RI is automatically configured by the gCore to join the VO(s) expressed in the [[Scope_Management#Static_scope_for_gHN|startScopes]] parameter of the GHNConfig.xml.
  
 
== gCube Calls & the gCube Handler ==
 
== gCube Calls & the gCube Handler ==

Latest revision as of 09:35, 9 September 2008

What's in Scope?

In gCube, a resource may only be shared within one or more scopes. Outside these, the resource can neither be discovered nor used.

A Running Instance, in particular, may operate in different scopes at different times. For this to happen, clients must specify a scope when contacting the instance. Similarly, any state which the instance might create must retain the scope of the call which triggered the creation.

It is so that resources, WS-Resources, and calls are all scoped in gCube.

Modelling Scope

In gCube, there are three levels of scope: the Infrastructure, the Virtual Organization (VO), and the Virtual Research Environment (VRE).

The levels are hierarchically related: the VRE groups resources which satisfy the requirements of a particular application, the VO groups resources which support the operation of one or more VREs, and the infrastructure groups resources which support the operation of one or more VOs. In particular, a VRE exists only in the context of a VO which in turn exists in the context of some infrastructure. Informally, we say that the VRE is below the VO and that the infrastructure is above it.

We use expressions of the form /A/B/C to denote a VRE C below a VO B below an infrastructure A. Informally, /A/B/C may be thought of as the fully qualified name of C. More formally, we use the following grammar for scope expressions: 

SCOPE ::= I | VO | VRE
I ::= /NAME
VO ::= I/NAME
VRE ::= VO/NAME
NAME ::= <a conventional label>

In gCF, scope expressions can be conveniently thought as serialisations of GCUBEScope objects. to be continued...

Scope Rules

Scoping in gCube is rooted on a first, basic rule: 

R1) a resource in the scope of a VO is also in the scope of the VREs below.

So, a resource in /A/B is also in /A/B/C but not necessarily in /A or in /A/D.

R1 captures the intuition that resources shared by a Virtual Organization are immediately available to all its applications. As noted above, these resources are most often dedicated to the management of the VREs: gCube Hosting Nodes and Running Instances of Core services have typical example of VO-level resources.

Note: The converse of R1 does not hold: a resource shared in a VRE may be dedicated to it. That is, it may not be shared in the VO above (and, for R1), in the other VREs of that same VO).

Note: R1 does not extend to infrastructure scope: a resource in that scope may not be automatically shared in the VOs below. This captures the intuition that most resources with infrastructure scope manage VOs in a way which is transparent to them, 'in the background'.

We now consider additional rules which restrict, widen, or simply complement R1 in reflection of the semantics and pragmatics of individual resources types.

Scoping Rules for gCube Hosting Nodes

Sharing in gCube starts with GHNs, the main fabric of the infrastructure. GHNs are first pooled at the infrastructure scope and, in accordance with R1), must be explicitly joined to one ore more VOs. The rules which govern the sharing of GHNs are constrained by the following rules: 

GHN1) all the scopes of a GHN must be rooted in the same infrastructure.
GHN2) a GHN in a given scope is also in the scopes above.

GHN1 rules assert that GHNs cannot be shared across infrastructures (though the machine on which they run can of course). GHN2 states that the converse of R1 holds for GHNs and is mainly an implication of infrastructure monitoring requirements.

Note: gCore allows site administrators to configure their GHN to start in zero ore more VOs. gCF enforces GHN1 by making sure that the start VOs are all rooted in the same infrastructure. It then uses GHN2 to optimise scope management (keeps rack only of VO scopes).

Scoping Rules for gCube Services

Let SV be a gCube Service. 

SV1) if SV is shared in a scope it is also shared below it: SV in S => for each S' in S. R in S'

Note: This extends R1) to infrastructure-level scope make scoping simplest for services.

gCore implications: none special, scopes are immutable for services (i.e. for the ones already deployed).

Scoping Rules for Running Instances (RIs) of gCube services

Running instances are a first example of resource type for which scoping rules are further constrained by the scope of related resources. In fact, running instances relate to their services and the hosting nodes on which they are deployed.

Let SV(RI) and GHN(RI) denote, respectively, the service of a RI and the GHN on which the RI is deployed. 

RI1) RI can only be shared where its GHN and service can: RI in S => GHN(RI) in S and SV(RI) in S

Note: The opposite of RI1) does not hold: a RI is not necessarily shared wherever its GHN and its service are.

gCore implications:

  • on add, enforce RI1) (ServiceContext)
  • on startup,
    • generic service: subscribe consumer for GHN remove scope events only (ServiceContext) => remove all RI scopes contained in those removed from the GHN (consumer).
    • local service: subscribe consumer for GHN remove and add scope events (ServiceContext) => add new GHN scopes to RI (consumer).
  • on bootstrap,
    • allow JNDI configuration of zero or more start scopes (RIBuilder)
    • static only : add all GHN scopes if no start scopes are available (RIBuilder). Prevent in dynamic bootstrap.

Scoping Rules for WS-Resource generated by Running Instances of gCube services

WS-Resources are anther example of resource type for which scoping rules are further constrained by the scope of related resources, in this case the running instance which generate them. Let WSR denote a WS-Resource and RI(WSR) the RI through which has generated WSR. 

WSR1) WSR can only be shared where its RI can: WSR in S => RI(WSR) in S

Note: The opposite of RI1) does not hold: a RI is not necessarily shared wherever its GHN and its service are.

gCore implications:

  • on creation, enforce WSR1) (GCUBEHandler)
  • on remove, remove from all WS-Resource which have been created by some stateful-port-type of the RI below the removed RI scope;
    • due to persistence, cannot be easily performed locally, use instead queries to the IS

Configuring scope (Static scope)

Static scope applies only for those resources that can be manually created by humans. For such gCube resources, a scope S can be statically (i.e. manually) configured and changed through their appropriate configuration files.

Static scope for gCube Hosting Nodes

A gHN is always manually deployed, therefore a static scope configuration is always needed. Such a configuration is expressed with two parameters in the $GLOBUS_LOCATION/config/GHNConfig.xml file.

  • infrastructure reports the GI the gHN joins (and it can be one and only one, as for GHN1). In the following example, the gHN is configured to join the /gcube infrastructure:
 <environment
        name="infrastructure"
        value="gcube"
        type="java.lang.String"
        override="false" />
  • startScope is a comma-separated list of VOs the gHN joins. These VOs has to be below the infrastructure (as for GHN2)), otherwise they are ignored. The list of VOs can be an empty list. In the following example, the gHN is configured to join both the /gcube/devsec and the /gcube/testing VO:
<environment
        name="startScopes"
        value="devsec,testing"
        type="java.lang.String"
        override="false" />

Static scope for gCube Services

A gCube service has always only a static scope, specified at service registration time in the Software Repository service.

Static scope for Running Instances (RIs) of gCube services

Static scope for RIs has a mean only for those that are manually deployed. A RI can be configured to join one or more VOs and/or VREs with a comma-separated list. Due to RI1), the VOs has to be a subset of the VOs to which the GHN(RI) is joined to and the VREs has to be below the VOs to which the GHN(RI) is joined to.

In order to specify the static scope of a RI, insert a startScopes parameter in the service context section of the JNDI's RI with the fully qualified name of the scope as follows: 

<service name="gcube/common/vremanagement/Deployer">
	
	<environment 
		name="configDir" 
	 	value="@config.dir@" 
	 	type="java.lang.String"
	 	override="false" />
		 		 	
	<environment 
		name="securityManagerClass" 
	 	value="org.gcube.common.core.security.GCUBESimpleServiceSecurityManager" 
	 	type="java.lang.String"
	 	override="false" />
	 	
	<environment 
		name="startScopes" 
	 	value="/gcube/devsec/EM,/gcube/testing/test1" 
	 	type="java.lang.String"
	 	override="false" />

</service>

Note: The startScopes parameter is optional: if it is not used, the RI is automatically configured by the gCore to join the VO(s) expressed in the startScopes parameter of the GHNConfig.xml.

gCube Calls & the gCube Handler

[coming soon]

Scope Managers

[coming soon]

The Client Perspective:Scopes & Stubs

Retrieved from "https://gcore.wiki.gcube-system.org/index.php?title=Scope_Management&oldid=861"